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Abstract 


This  thesis  considers  the  interaction  of  programs  with  a 
semantic  network  formalism  for  organizing  knowledge,  and 
continues  with  a  description  of  a  computer  implementation  of 
the  procedural  semantic  network  formalism  described  by 
H.  Levesque  in  "A  Procedural  Approach  to  Semantic  Networks” 
(Technical  Seport  No.  105,  Department  of  Computer  Science, 
University  of  Toronto) .  Programs  in  the  formalism  are  objects 
examinable  from  the  formalism,  and  are  important  because  they 
are  used  to  provide  the  semantics  of  classes.  This  thesis 
provides  fools  which  further  help  the  representation;  in 
particular,  it  introduces  a  tool  for  organizing  the  structure 
of  classes  and  uses  this  mechanism  to  organize  the  parts  of 
programs.  The  implementation  provides  a  translator  which 
transforms  an  input  language  into  objects  within  the  network, 
and  an  interpreter  which  executes  these  objects  as  programs. 
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CHAPTER  I 
Introduction 


The  procedural  semantic  network  formalism  is  a 
representing  and  organizing  the  large  amounts  o 
often  required  by  the  solutions  to  problems  in 
intelligence.  This  thesis  describes  a  computer  imp 
of  the  formalism  and  provides  a  new  declarative  desc 
programs  within  the  model. 
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The  philosophy  of  the  procedural 

formalism  (PSN)  is  to  provide  a  small  ke 
functions  and  a  set  of  declarative  construe 
expressible  in  terms  of  the  kernel.  It  is 
to  seek  a  representation  oc  programs  whic 
model.  Although  such  representations  have 
older  versions  of  PSN ,  there  has  be 

improvement,  especially  in  the  representati 
(or  statements)  in  a  program. 


semantic  netw 
rnel  of  primit 
ts  all  of  which 
natural  thereto 
h  uses  the  exist 
been  proposed 
en  some  room 
on  of  expressi 


ork 
i  ve 
are 
re, 
ing 
in 
f  or 
ons 


The  computer  implementation  of  PSN  incorporates  this  new 
model  of  programs  in  addition  to  the  standard  features  of  the 
formalism.  Previous  implementations  have  been  less  complete  in 
that  the  procedures  defining  the  semantics  of  PSN  objects  have 
been  LISP  code.  Also,  these  systems  supplied  little  more  than 
the  basic  kernel  of  PSN.  The  new  implementation  provides  a 
language  which  includes  many  of  the  declarative  constructs, 
thus  providing  a  more  habitable  environment  for  a  user  of  the 
syst  em. 
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1.1.  Overview 
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The  PSN  formalism  consists  of  semantic  network  primitives 
representing  knowledge,  and  a  language  in  which  changes  in 
knowledge  represented  can  be  expressed.  The  basic 
itive  is  the  object;  the  most  primitive  transformation  of 
knowledge  base  is  the  creation  of  a  new  object  as  in 

"John  :=  new  object  end". 

name  "John"  is  an  external  name  for  the  new  object  and  can 
sed  in  the  language  or  in  text  to  refer  to  this  object. 


Objects  can  be  related  through  the  relation  INS 
follows: 

" make  John  instanceo  f  PERSON". 

The  object  referred  to  by  "John"  is  now  what  is  kn 
instance  of  the  class  "PERSON".  Classes  play  a  ver 
role  in  the  formalism;  in  addition  to  providing  a 
separating  objects  in  various  categories,  classes  sp 
behaviour  through  four  attached  programs.  In 
example,  the  transformation  which  makes  "John"  an 
"PERSON"  is  specified  by  the  to-add  program  of  the 
is  this  procedural  attachment  which  gives  the  fo 
name  and  makes  programs  an  important  area  of  study  w 
to  PSN. 

Included  in  the  definition  of  a  class  is  a  me 
defining  structural  properties  which  an  instance  of 
may  have.  The  structural  properties  of  an 
properties  which  the  user  of  the  formalism  de 
essential  to  the  description  of  the  object.  For  ex 
person  could  have  as  structural  properties  a  sex  a 
colour.  The  definition  of  "PERSON"  would  then  be 
"PERSON  :=  new  CLASS 
structure 

sex  :=  a  SEX_ VALUE  end  slot 
eye_colour  :=  a  COLOUR  end  slot 
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and  instances  of  this  class  could  be  assigned  values  for  these 
properties  as  in 

’’John  $  ,eye_colour  <-  blue”. 

For  each  individual  property  definition  (for  example  sex)  an 
object  called  a  slot  is  created  and  associated  with  the  class. 
This  set  of  slots  is  known  as  the  structure  of  the  class.  The 
class  following  the  ’’a"  in  the  slot  definition  is  known  as  the 
type  of  the  slot  and  is  used  to  restrict  the  values  which  may 
be  assigned  for  that  property.  Tf  “blue”  were  not  an  instance 
of  ’’COLOUR”,  the  assignment  illustrated  above  would  fail.  In 
general,  a  property  value  must  be  an  instance  of  the  class 
which  is  the  type  of  the  slot  defining  that  property. 

The  first  problem  to  which  this  thesis  addresses  itself  is 
the  organization  of  the  slots  defined  in  a  class.  In 

particular,  one  would  like  to  group  these  slots  (property 
definitions)  into  different  categories.  The  organizing 
mechanism  for  structure  is  known  as  metastructure.  This 
mechanism  provides 

1.  the  ability  to  distinguish  categories  of  slots  in  the 
instance  class;  that  is,  where  previously  one  could  only 
ask  for  all  of  the  slots  of  a  class,  one  can  now  fetch 
all  slots  in  the  class  which  belong  to  a  given  category. 
This  mechanism  finds  useful  application  in  the 
representation  of  programs  proposed  in  this  thesis, 

2.  the  ability  to  define  properties  of  a  slot.  In 
particular,  the  type  of  a  slot  can  be  explained  as  a 
property  of  the  slot. 

3.  the  ability  to  specify  a  minimum  and  maximum  number  of 
instances  of  a  given  category  which  may  appear  in  a 
class . 

In  effect,  metastructure  constrains  the  structure  of  classes 
while  the  structure  of  a  class  constrains  the  property  values 
of  instances  of  that  class. 
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The  motivation  for  the  work  on  programs  begins  with  a 
second  important  relation  of  PSN.  The  relation  IS-A  is  a  map 
between  two  classes,  one  of  which  becomes  known  as  a  subclass 
and  the  other  as  a  superclass  or  IS-A  parent.  The  relation  is 
characterized  as  follows: 

1.  each  instance  of  the  subclass  must  be  an  instance  of  the 
superclass,  and 

2.  all  of  the  structure  of  the  superclass  is  contained  in 
the  structure  of  the  subclass. 

The  first  property  has  important  conseguences  for  programs:  as 
mentioned  earlier,  an  object  is  made  an  instance  of  a  class  by 
the  to-add  program  of  the  class.  Now  if,  for  example, 
"STUDENT"  is  a  subclass  of  "PERSON",  the  add  program  of 
"STUDENT"  must  insure  that  an  object  added  to  the  class  is  also 
made  an  instance  of  "PERSON".  Thus,  if 
"STUDENT  :=  new  CLASS  isa  PERSON; 

Mary  :=  new  STUDENT" 

were  executed,  "Mary"  should  be  an  instance  of  both  "PERSON" 
and  "STUDENT". 


The  direction  taken  here  is  to  allow  IS-A  to  relate 
programs  (by  representing  programs  as  classes)  and  insisting 
that  the  programs  of  a  class  be  IS-A  parents  of  the 
corresponding  programs  of  a  subclass  of  that  class.  The  means 
of  associating  actions  with  a  class  in  using  it  to  represent  a 
program  must  be  such  that  IS-A  related  programs  act  so  that  the 
first  condition  for  IS-A  is  satisfied. 

The  solution  proposed  in  this  thesis  does  not  completely 
insure  this  requirement.  What  is  provided,  however,  is  a  set 
of  declarative  rules  which  must  be  satisfied  for  one  program  to 
be  an  IS-A  child  of  another,  and  an  operational  specification 
of  how  the  actions  of  two  such  programs  must  be  related.  The 
latter  is  accompanied  by  guide  lines  which  indicate  when  the 
constraints  of  IS-A  would  be  violated.  This  is  done  in  terms 
of  inheritance:  if  one  program  IS-A  another,  it  inherits  the 
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actions  of  its  parent.  Thus  if 

"prog rami  :=  program  ...  end  program; 
program2  :=  program  ...  isa  program  1  end  prog. ram" 

(where  the  indicates  the  actions  of  each  program)  were 
in  effect,  all  of  the  actions  of  "program  1"  are  inherited  by 
"program2"r  and  "program2"  is  legally  an  IS-A  descendant  of 
"program  1"  only  if  no  action  which  is  supplied  in  addition  to 
those  inherited  undoes  the  effects  of  an  inherited  action. 

The  final  problem  for  which  this  thesis  proposes  a 
solution  is  a  computer  implementation  of  the  PSN  formalism. 
This  implementation  will  take  as  input  commands  in  the  language 
of  which  examples  were  shown  above  and  perform  the  reguired 
changes  in  a  knowledge  base.  The  system  must  therefore  provide 
a  computer  representation  of  the  network  structure.  This 
includes  a  representation  of  objects,  the  IS-A  and  INSTANCE-OF 
relations,  structure  and  metastructure,  and  procedural 
attachment.  A  translator  is  reguired  to  transform  the  input 
language  into  PSN  objects  which  represent  the  commands  which 
can  then  be  interpreted  by  an  interpreter  of  PSN  programs. 

The  language  implemented  is  based  on  that  of  the  original 
description  of  PSN  ([Levesque  1977  ])  with  modifications  for  the 
new  proposals  of  this  thesis  and  to  make  the  task  of  parsing 
simpler.  The  major  PSN  features  of  the  language  are  constructs 
for  creating  objects  and  invoking  the  standard  programs  which 
are  attached  to  classes.  In  addition  it  includes  standard 
arithmetic  and  logical  expressions  and  for,  if,  and  begin 
control  structures.  The  innovations  involve  the  syntax  for 
defining  metastructures,  for  categorizing  slots,  and  for 
specifying  inheritance  in  programs. 

In  addition  to  providing  a  language  in  which 
transformations  can  be  specified,  an  implementation  must  supply 
standard  procedures  which  can  be  attached  to  the  classes  of  a 
knowledge  base.  These  will  generally  be  used  for  what  are 
known  as  stored  or  add-defined  classes;  such  classes  are 
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characterized  by  the  fact  that  instances  are  identified  by 
physically  stored  INSTANCE-OF  links.  The  standard  routines  are 
primitive  in  that  they  are  capable  of  creating  and  accessing 
such  stored  links.  In  contrast,  test  defined  classes  do  not 
require  the  use  of  such  routines.  For  example,  one  might 
define  a  class  of  blue  eyed  objects  by  associating  with  it  a 
test  routine  which  tests  for  an  ”eye_colour”  equal  to  ’’blue”. 
This  test  procedure  would  be  written  in  the  PSN  language  and 
does  not  involve  the  invocation  of  a  standard  routine. 

Another  aspect  of  the  implementation  is  the  provision  of 
the  inheritance  mechanism.  The  major  effort  is  in  the 
inheritance  of  structure:  this  involves  associating  slots  with 
classes,  discovering  which  slots  are  to  be  inherited  (insuring 
that  no  conflicting  definitions  are  inherited) ,  and  adding  the 
new  properties  to  the  new  view  of  each  slot.  The  inheritance 
of  values  (where  a  property  value  of  a  class  is  found  by 
looking  at  its  IS-A  parents)  involves  finding  all  possible 
sources  of  inherited  values  and  checking  that  a  unique  value 
may  be  determined. 

The  final  aspect  of  the  implementation  is  the  interpreter. 
This  program  is  used  to  interpret  the  PSN  classes  which  are 
programs  to  produce  the  desired  changes  in  the  knowledge  base. 
When  a  program  is  executed,  an  instance  of  the  class  which  is 
the  program  is  created.  The  concerns  of  the  interpreter  are 
the  creation  and  termination  of  such  instances,  the  association 
of  the  state  of  execution  with  these  instances,  and  recording 
the  relationships  between  such  instances  with  the  purpose  of 
maintaining  the  dynamic  order  of  execution. 

An  important  concern  in  the  design  of  the  implementation 
is  the  final  environment  in  which  a  user  will  find  himself. 
This  results  in  an  interactive  parser  for  the  language  which 
allows  the  user  to  correct  errors  as  they  are  found  through  the 
use  of  special  control  tokens. 
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1.2.  Background 


The  original  description  of  PSN  is  found  in  [Levesque 

1977] .  This  work  also  provides  informally,  the  language  which 
is  a  model  for  that  used  in  the  current  implementation. 
[Levesque  and  Mylopoulos  1978]  provides  a  good  introduction  to 
the  formalism.  Although  it  is  a  semantic  network  formalism, 
the  traditional  diagrams  including  nodes  and  arcs  were  not  used 
in  the  original  description  of  PSN.  [Levesque  and  Mylopoulos 

1978]  introduces  such  a  notation  for  the  formalism. 


An  early  use  of  PSN  for  the  represe 
artificial  intelligence  is  described 
This  project  revealed  several  weaknesses 
which  solutions  were  proposed  in  [S 
solutions  are  summarized  in  [Schneide 
improved  somewhat  the  representati 
subsequent  evolution  of  the  formalism  h 
unusable . 
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An  alternate  stream  of  research  originating  from 
resulted  in  the  language  known  as  TAXIS  ([  Mylopoulos 
1978]  and  [Wong  1980]).  This  language  is  intended 
design  of  interactive  information  systems,  taking  fr 
primarily  the  organizational  tools.  These  tools  ha 
extended  with  much  more  concentration  on  the  representat 
programs  than  has  been  applied  in  PSN.  The  new  represe 
of  programs  in  PSN  finds  Its  roots  in  the  programs  of 
The  fundamental  differences  between  the  version 
described  in  this  thesis  and  TAXIS  are: 


PSN  has 
e  t  al. 
for  the 
om  PSN 
ve  been 
ion  of 
ntat ion 
TAXIS, 
of  PSN 


1.  PSN  allows  the  dynamic  creation  and  destruction  of 
classes  while  TAXIS  treats  them  as  data  types  to  be 
defined  at  compile  time  In  the  usual  programming 
language  sense. 

2.  PSN  requires  that  expressions  (that  is,  calls  to 
programs  as  in  SQET{5))  be  represented  as  objects  within 
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the  formalism.  In  TAXIS ,  the  representation  of  an 
expression  is  an  atomic  (non-decomposable)  unit  on  which 
no  operation  but  evaluation  is  defined.  One  advantage 
of  the  PS  N  view  is  that  the  specialization  of 
expressions  is  represented  declaratively,  while  in  TAXIS 
this  can  be  expressed  only  in  terms  of  a  special 
predicate  which  returns  true  if  one  argument  is  a 
specialization  of  the  second. 

3.  TAXIS  uses  what  it  calls  property  categories  to  organize 
the  expressions  of  a  program.  These  categories  are  not 
declarati vely  defined.  PSN  provides  a  general  concept 
of  metastructures  which  are  definitions  in  a  metaclass 
constraining  the  definitions  of  properties  in  classes. 

4.  TAXIS  has  a  tool  known  as  complex  properties.  Such 
properties  find  use  in  the  exception  handling  mechanism. 
When  the  exception  handling  mechanism  is  adapted  to  PSN, 
complex  properties  are  not  available,  and  the 
representation  becomes  somewhat  different  from  that  in 
TAXIS. 

5.  In  PSN  execution  of  programs  is  accomplished  by  a 
program  which  interprets  objects  within  the  formalism. 
TAXIS  executes  compiled  code. 


The  previous  implementations  of  PSN  are  described  in 
[Berlin  1978]  and  [Graham  and  Kramer  1919].  Experiments  in  the 
use  of  Berlin’s  system  are  described  in  [Lesperance  1979  ]. 
This  work  is  a  useful  source  of  suggestions  relevant  to  the 
design  of  an  implementation  originating  from  problems 
encountered  in  the  use  of  such  a  system. 


I. 3  Outline 
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1.3.  Out  line 

The  current  version  of  PSN  is  described  in  chapters  two 
and  three.  Chapter  two  summarizes  the  features  introduced  in 
previous  work  and  therefore  serves  as  an  introduction  to  the 
formalism.  Chapter  three  introduces  the  new  modifications  to 
the  model.  This  includes  the  introduction  of  metastructure  and 
the  new  representation  of  programs. 

The  implementation  of  the  model  is  discussed  in  chapters 
four  and  five.  The  standard  procedures  for  storing,  killing, 
testing,  and  fetching  objects  are  described  in  chapter  four. 
This  corresponds  roughly  to  what  has  been  done  in  previous 
implementations.  Chapter  five  continues  with  a  description  of 
the  parser  for  the  language  and  the  interpreter  of  PSN 
programs . 


CHAPTER  II 
Description  of  PSN 


II. 1 .  Introduction 


Although  it  is  possible  to  work  in  PSN  usin 
and  programs  operating  on  these  objects,  the  for 
several  organizational  tools  designed  to  structu 
representing  knowledge.  These  declarative  tool 
the  relationships  between  various  objects  a 
knowledge  in  the  knowledge  base.  This  chapter 
fundamental  constructs  of  PSN:  a  way  of  categori 
means  of  types,  a  way  of  associating  propertie 
and  a  means  for  specialization  of  types. 
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A  PSN  knowledge  base  in  its  basic  form  consists  solely  of 
objects  some  of  which  are  procedures  which  provide  the 
semantics  for  the  objects  to  which  they  are  attached.  It  is 
however  convenient  to  consider  the  knowledge  base  from  a  higher 
declarative  viewpoint.  From  this  view  the  knowledge  base 
shares  features  with  other  semantic  network  formalisms.  In 
particular,  the  knowledge  base  consists  of  objects  and 
relationships  between  these  objects.  When  considered  in  this 
fashion  it  is  natural  to  use  a  diagrammatic  notation  and 
vocabulary  to  describe  features  of  the  representation,  thus  the 
word  node  may  often  be  used  for  object,  and  terms  such  as  link 
or  arc  may  be  used  to  express  the  fact  that  a  relationship 
exists  between  two  objects. 


There  are  three  basic  declarative 
characterize  the  PSN  formalism.  These 
provides  a  means  of  giving  objects  types, 
objects  structure  and  in  particular 


relationships  which 
are  INSTANCE-OF  which 
PA  RT-OF  which  gives 
explains  procedural 
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attachment,  and  IS- A  which  provides  a  means  of  relating  types. 
These  tools  interact  through  the  inheritance  mechanisms  and 
thus  provide  a  powerful  means  of  describing  knowledge. 

The  diagrammatic  notation  will  be  relied  on  heavily  to 
provide  illustrations  of  the  declarative  structures  of  the 
formalism.  It  will  become  necessary  to  refer  to  the  objects 
and  relationships  expressed  by  the  figures.  Objects  are 
represented  as  points  or  boxes  usually  accompanied  by  a  label. 
This  label  is  an  example  of  an  external  name.  In  general,  an 
external  name  is  simply  a  means  of  referring  to  objects  of  some 
?SN  knowledge  base  from  the  text;  it  is  not  a  part  of  the 
formalism.  Such  references  to  objects  will  be  enclosed  in 
quotation  marks  (""").  For  example,  figure  2-1  illustrates 
objects  refered  to  by  '’John'1  and  ''PERSON'1. 

Diagrams  will  represent  relationships  between  objects  by 
arcs.  In  many  cases  the  arcs  will  be  labelled;  however  there 
are  two  types  of  arc  which  occur  commonly  and  are  not  labelled. 
An  unlabelled  arc  with  a  single  shaft  represents  the 
relationship  INSTANCE-OF  described  in  section  2. 2,  and  the 
unlabelled  arc  with  a  double  shaft  represents  the  IS-A  relation 
described  in  section  2.4.  Figure  2-1  includes  an  example  of 
each  of  these  arcs. 

II. 2.  INSTANCE-OF 

Every  object  is  related  to  at  least  one  other  object 
through  the  INSTANCE-OF  relation.  The  set  of  objects 
associated  to  an  object  through  this  relation  are  known  as  the 
t/ype s  of  the  object.  Only  objects  whose  types  include  the 
special  object  "CLASS"  may  be  types  of  other  objects.  Such 
objects  are  known  as  classes ;  objects  whose  types  include  a 
given  class  are  known  as  instances  of  that  class.  For  example, 
the  class  "PERSON"  would  have  as  instances  all  objects  in  the 
knowledge  base  which  are  intended  to  represent  people. 
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STUDENT. 
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figure  2-1 


figure  2-2 
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Classes  play  a  very  significant  role  in  a  PSN  knowledge 
base.  Through  four  programs  which  are  attached  to  each  class, 
the  class  determines  the  behaviour  of  its  instances.  In 
addition,  as  will  be  discussed  in  the  next  section,  classes 
define  the  properties  that  an  object  may  have.  It  is  the 
attachment  of  the  programs  that  gives  the  formalism  its 
procedural  aspect. 

The  action  of  asserting  that  a  class  is  to  become  a  type 
of  an  object  is  known  as  making  the  object  an  instance  of  the 
class.  This  operation  is  controlled  by  what  is  known  as  the 
to-add  program  of  the  class.  This  program  will  usually  cause 
some  kind  of  storage  operation  which  will  indicate  that  the 
object  is  an  instance  of  the  class.  In  addition,  it  can  check 
that  the  object  satisfies  certain  conditions  for  becoming  a 
member  of  that  class  and  can  perform  actions  with  side  effects 
which  are  characteristic  of  instances  of  the  class.  For 
example,  to  implement  two  classes  whose  sets  of  instances  are 
to  be  disjoint,  the  to-add  programs  of  each  class  would  check 
that  new  instances  are  not  members  of  the  other  class. 

The  to-kill  program  of  a  class  undoes  the  effects  of  the 
to-add  program,  that  is,  it  modifies  the  knowledge  base  so  that 
an  object  is  no  longer  an  instance  of  the  class.  Again,  in 
addition  to  removing  the  link  between  object  and  class,  this 
program  may  perform  additional  actions  necessary  for  complete 
removal.  The  to-kill  program,  too,  may  check  prerequisite 
conditions  for  removal  and  fail  if  they  are  not  satisfied. 

A  third  action  associated  with  classes  is  testing  for 
membership.  This  is  the  purpose  of  the  to- test  program.  In 
its  simplest  form  a  to- test  program  will  simply  check  for  the 
existence  of  a  link  between  an  object  and  the  class.  In  other 
cases,  one  might  have  classes  whose  instances  are  not 
explicitly  linked  to  the  class,  and  the  to-test  program  would 
check  other  conditions  for  membership.  For  example,  the 
program  for  a  class  5,UNION_A_B,,  might  return  true  if  an 
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instance  is  a  member  of  either  class  "A”  or  class  nBn. 

The  final  program  attached  to  classes  is  the  to-f e tch 
program  whose  responsibility  is  to  make  available  all  instances 
of  a  class.  This  program  would  be  invoked  in  code  such  as 

"for  X  in  CL ASS_A  do  <statements>  end” 
where  as  the  iteration  progresses,  the  variable  "X"  would  take 
on  the  value  of  a  different  instance  of  "CLASS_A".  In  the 
example  of  11  ONION_ A_B"  the  to-fetch  program  could  invoke  the 
to-fetch  programs  of  each  of  the  classes  "A"  and  MBn  and  return 
the  set  union  oE  the  results.  Alternatively,  a  better 
algorithm  is  to  fetch  all  the  instances  of  one  class  and  return 
those  for  which  the  test  program  of  the  other  class  returns 
true . 


As  indicated  in  the  introduction,  the  INSTANCE-OF  link  is 
represented  in  diagrams  as  an  unlabelled  arrow  with  a  single 
shaft.  A  class  is  often  represented  by  a  box  to  distinguish  it 
from  objects  which  are  not  classes.  Procedural  attachment  to  a 
class  is  indicated  by  the  arcs  labelled  with  the  names  of  the 
respective  programs  as  illustrated  in  figure  2-2.  Since 
programs  are  part  of  the  formalism,  they  are  objects  having 
types;  in  particular  programs  are  objects  which  are  instances 
of  the  class  "PROGRAM".  The  details  of  the  representation  of 
programs  will  be  discussed  in  chapter  three.  At  this  point  it 
suffices  to  note  that  "PROGRAM",  being  a  class,  will  have 
attached  to  it  programs  for  the  four  operations  which  create, 
destroy,  test  for,  and  fetch  programs. 

Figure  2-2  also  illustrates  what  is  known  as  the 
INSTANCE-OF  hierarchy.  "John",  "PERSON",  and  "CLASS"  are 
objects  at  distinct  levels  in  the  representation  known  as  the 
object,  class,  and  meta  levels  respectively.  A  metaclass  is  a 
class  whose  instances  are  themselves  classes.  The  need  for  an 
infinite  number  of  levels  where  an  object  on  one  level  is  an 
instance  of  some  object  of  the  next  higher  level  is  obviated  by 
making  "CLASS"  an  instance  of  itself.  This  property  of  "CLASS" 
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is  also  made  necessary  by  the  rule  which  requires  that  types  be 
instances  of  this  object. 

Another  interesting  object  which  must  exist  in  a  PSN 
knowledge  base  is  the  class  "OBJECT*1  which  has  as  instances  any 
existing  object.  This  includes  objects  from  any  level  of  the 
INSTANCE-OF  hierarchy,  and  necessarily  includes  "OBJECT" 
itself. 

II. 3.  PART-OF 

Objects  of  the  same  type  generally  are  grouped  together 
because  they  share  certain  properties  which  characterize  the 
class.  For  example,  objects  which  represent  people  will 
certainly  have  properties  describing  their  sex,  eye  colour, 
race,  etc.  PSN  provides  a  mechanism  for  describing  such 
properties  of  instances  in  the  definition  of  the  class.  This 
description  is  known  as  the  structure  of  the  class.  This 
structure  is  composed  of  a  set  of  structural  property 
definitions ,  commonly  referred  to  as  slots. 


Corresponding  to  each  slot  there  must  be  a  structural 
property  value  (or  slot  value)  for  each  instance  of  the  class. 
Once  assigned,  a  slot  value  may  not  be  changed  during  the  life 
of  an  object.  In  general,  an  object  may  be  an  instance  of  more 
than  one  class  and  therefore  has  slot  values  corresponding  to 
the  slots  defined  in  each  of  its  types. 


A  structural  property  definition  serves  three  purposes. 
First,  it  specifies  that  there  must  be  a  corresponding 
relationship  between  an  instance  of  the  class  and  some  other 
object.  For  example,  a  slot  "S_I_N"  in  the  class  "PERSON" 
would  indicate  that  each  person  has  a  social  insurance  number. 
Secondly,  it  specifies  the  types  of  which  the  slot  value  must 
be  an  instance.  This  set  of  classes  is  known  as  the  type  of 
the  slot.  The  type  of  the  slot  "S_I_N"  would  include  the  class 
"NUMBER".  The  third  aspect  of  a  slot  is  the  restriction  which 
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is  a  predicate  which  further  constrains  the  choice  of  a 
corresponding  slot  value.  A  restriction  on  the  slot  ,,S_I_N" 
might  be  that  the  number  must  have  nine  digits. 

Another  property  which  is  associated  with  a  slot  is  the 
default  value.  This  value  will  be  the  slot  value  of  an 
instance  if,  at  the  point  at  which  the  property  is  queried,  no 
previous  value  has  been  assigned  and  no  inherited  (section  2.4 
discusses  inheritance)  value  was  available. 

The  slots  which  make  up  the  structure  of  a  class  are 
represented  by  PSN  objects,  and  therefore  may  have  types  and 
property  values.  The  class  of  which  slots  are  instances  is 
known  as  "slot" .  The  objects  which  form  the  structure  of  a 
class  are  said  to  exist  within  that  class.  An  object  which 
exists  inside  a  class  is  an  object  which  has  a  unique 
association  with  the  class;  the  relationship  between  such  an 
object  and  its  containing  class  is  known  as  PART-OF.  Objects 
which  exist  within  a  class  must  have  among  their  types  at  least 
one  object  which  is  PART-OF  a  parent  class  of  the  class.  There 
is  here  a  potential  ambiguity  in  the  use  of  the  word  "type": 
when  discussing  objects  it  means  the  set  of  classes  of  which  an 
object  is  an  instance;  when  discussing  slots  it  is  a  set 
constraining  the  corresponding  slot  values.  Slots  are  however 
objects.  In  general  it  will  be  obvious  which  sense  is 
intended . 

In  diagrams  the  structure  of  a  class  is  represented  by 
objects  contained  within  the  box  representing  the  class. 
Objects  which  are  instances  of  the  class  "slot"  will  generally 
be  labelled;  these  names  are  used  to  mark  the  arcs  joining 
instances  of  the  class  to  values  for  the  corresponding 
properties.  This  labelling  is  necessary  only  as  a  notational 
tool  and  says  nothing  of  how  the  association  is  represented  in 
a  potential  implementation. 

The  features  type,  restriction,  and  default  which  are 
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“CLASS".  Thus  these  values  are  also  linked 
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As  an  illustration  of  these  conventions,  consider  figure 
2-3.  This  shows  a  class  called  "STUDENT"  containing  a  single 
slot  which  represents  a  student  number.  "John"  is  an  instance 
of  student  with  number  "741353839".  The  slot  "number"  has  a 
single  type;  this  is  generally  the  case.  In  addition,  "number" 
is  an  instance  of  "slot"  which  is  contained  in  "CLASS".  "slot" 
is  not  itself  a  slot,  but  it  is  an  instance  of  "CLASS".  As  a 
class  it  may  have  instances  (for  example  "number")  and 
structure  (the  slots  "type",  "restriction",  and  "default"). 
The  diagram  shows  the  slots  of  this  class  as  objects  within  the 
box  representing  "slot";  these  slots  are  parts  of  "slot",  not 
of  "class".  Since  they  are  slots,  these  objects  are  instances 
of  the  class  "slot"  which  is  at  the  same  time  the  class  which 
contains  them. 

At  this  point  in  the  discussion,  no  object  has  been 
introduced  which  has  "slot"  as  an  instance  and  is  part  of  a 
type  of  "class".  It  will  therefore  become  necessary  to 
introduce  a  new  class  which  will  contain  such  an  object.  This 
will  however  be  left  until  the  discussion  of  metastructure  in 
chapter  three. 


It  is  now  possible  to  complete  the  explanation  of 
procedural  attachment  to  classes.  The  metaclass  "CLASS"  has  as 
slots  in  its  structure  places  for  the  four  programs  described 
earlier.  An  individual  class  may  then  have  values  for  these 
slots.  Should  no  value  be  provided,  the  default  value  may 
generally  be  used.  Figure  2-4  illustrates  the  complete 
definition  of  "CLASS"  and  an  example  of  a  class.  In  this  and 
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figure  2-3 
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future  diagrams  the  INSTANCE-OF  link  from  a  slot  to  "slot”  is 
omitted  unless  it  is  necessary  for  clarity. 

II. 4.  IS -A 

Often  in  the  construction  of  a  knowledge  base,  one  will 
find  that  it  is  necessary  to  define  classes  where  the 
properties  of  one  class  are  similar  to  those  in  another  class. 
Differences  might  be  on  the  restrictions  on  some  slots:  for 
example  a  "MAN"  is  a  "PERSON"  whose  sex  is  restricted  to 
"MALE".  In  other  cases  slots  may  be  added:  the  class  "STUDENT" 
may  be  like  "PERSON"  with  the  addition  of  a  slot  for  a  student 
number.  In  both  these  cases  one  speaks  of  one  class  being  a 
speciali zation  of  the  other. 

In  both  the  examples  above,  it  is  also  true  that  an 
instance  of  the  more  specialized  class  is  also  an  Instance  of 
the  other  class;  a  man  is  generally  a  person.  These  two 
properties  characterize  the  PSN  relation  IS- A  between  two 
classes.  If  "A"  IS-A  "B"  then  "A"  is  a  subclass  of  "B"  and  " B" 
is  a  superclass  of  "A".  In  the  diagrams,  IS-A  is  represented 
by  an  arrow  with  two  shafts. 

That  an  instance  of  a  subclass  must  be  an  instance  of  the 
corresponding  superclass  must  be  reflected  by  the  test  and 
fetch  programs  of  the  classes.  That  requires,  for  example, 
that  for  every  object  for  which  the  test  program  of  "STUDENT" 
returns  true,  the  test  program  of  "PERSON"  must  also  return 
true.  The  implication  does  not  hold  in  the  other  direction. 
The  fetch  programs  must  be  related  so  that  the  set  of  objects 
returned  by  the  fetch  program  of  the  subclass  must  be  contained 
in  the  set  of  objects  returned  by  the  fetch  program  of  the 
superclass. 

The  passing  of  structure  from  a  class  to  a  subclass  is  an 
aspect  of  the  process  known  as  inheritance.  A  class  "S" 
inherits  from  a  superclass  "A"  any  object  which  is  defined  in 


20 


II. 4  IS-A 


"A"  and  is  an  instance  of  some  object  defined  in  some  type  of 
"B".  In  particular,  if  "3"  IS-A  "A",  all  the  slots  of  "A"  will 
be  slots  of  "B".  Figure  2-5  illustrates  what  may  happen  in 
inheritance  of  structure  along  IS-A.  The  slot  "number"  is 
shown  only  in  " GRAD_STUDENT"  because  it  is  inherited  without 
modification,  but  inheritance  implies  that  it  is  a  part  of 
" ?FD_STU  DENT" .  The  slot  "supervisor"  however  undergoes  a 
modification  in  inheritance.  This  does  not  imply  the  creation 

of  a  new  object  -  it  is  the  same  object  seen  in  a  different 

way.  In  modifying  the  properties  of  a  slot  one  must  obey  what 
is  known  as  the  IS-A  constraint.  For  "type"  this  constraint 
reguires  that  any  object  which  satisfies  the  types  of  the 
modified  slot  must  satisfy  the  types  of  the  original  slot. 
This  allows  both  the  addition  erf  new  types  and  the 
specialization  of  existing  types  as  "PROFESSOR"  is  a 
specialization  of  "PERSON"  in  the  example.  The  slot  "office" 
illustrates  that  new  properties  may  be  defined  in  the 
specialized  class. 

The  IS-A  constraint  manifests  itself  differently  for  the 
various  properties  of  slots.  Since  defaults  will  often  not  be 
classes,  no  constraint  can  be  applied  in  inheritance  because 
IS-A  is  not  defined  between  arbitrary  objects.  The 
relationship  between  restrictions  should  be  logical 
implication:  if  an  object  satisfies  the  restriction  of  the 
modified  slot  it  should  satisfy  the  restriction  on  the  original 
slot.  For  other  properties  on  slots,  the  general  rule  is  that 
the  value  for  the  modified  slot  must  be  IS-A  that  of  the 
original  slot. 

In  addition  to  inheriting  structure,  a  subclass  may 
inherit  property  values  from  a  superclass  in  the  process  of 
value  inheritance .  This  is  especially  useful  in  cases  where 
the  subclass  has  some  of  its  programs  in  common  with  its 
superclass.  For  example  in  figure  2-6  the  class  "STUDENT" 
differs  from  "PERSON"  only  through  a  different  test  program. 
Should  one  of  the  other  programs  be  required  in  an  operation  on 
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students,  the  inheritance  mechanism  will  find  the  appropriate 
program  at  the  level  of  the  class  "PERSON"  or  higher  if 
necessary.  Inherited  values  are  always  preferred  over  the 
default  value  of  a  slot. 

Value  inheritance  is  pre-emptive;  that  is,  if  a  value  is 
explicitly  specified  it  is  preferred  over  any  inherited  value. 
Therefore,  the  consistency  requirement  on  the  four  programs  of 
a  class  is  not  constrained  explicitly  through  the  inheritance 
mechanism.  One  is  tempted  to  create  an  IS-A  constraint  on  the 
values  of  properties,  so  that,  for  instance,  the  test  program 
of  a  class  must  be  a  specialization  of  the  program  of  a 
superclass  (it  must  be  pointed  out  that  the  PSN  definition  of 
programs  makes  programs  classes  and  hence,  the  IS-A  relation 
holds  between  them) .  However,  it  is  again  possible  to  define 
properties  of  classes  which  will  take  on  values  which  are  not 
classes  and  for  which  specialization  is  not  defined.  Thus  at 
present,  value  inheritance  in  PSN  remains  pre-emptive. 

Consider  the  case  where  "A"  IS-A  "B"  and  "B"  IS-A  "C". 
Then  an  instance  of  "A"  is  an  instance  of  "B"  and  therefore  an 
instance  of  "C".  The  structure  of  "A"  will  contain  slots 
inherited  from  "C"  via  "B"  and  any  modifications  of  inherited 
slots  will  satisfy  the  IS-A  constraint  going  from  "C"  to  "A". 
Finally,  any  values  which  were  not  pre-empted  in  the 
definitions  of  "A"  and  "3"  will  be  inherited  from  "C"  to  "A". 
Thus  it  is  apparent  that  IS-A  is  transitive  and  "A"  is  an  IS-A 
descendant  of  "C".  The  notion  of  transitivity  also  satisfies 
the  English  sense  of  the  word  "subclass":  a  subclass  of  a 
subclass  of  a  class  is  obviously  a  subclass  of  the  class. 

Because  IS-A  is  transitive,  the  resulting  structure  can 
legitimately  be  called  a  hierarchy.  When  the  IS-A  hierarchy 
presented  so  far  is  presented  as  a  diagram,  the  result  is  a 
tree  like  structure.  PSN,  however  does  not  constrain  the 
hierarchy  to  be  a  tree.  Thus  a  class  may  have  IS-A  parents 
which  do  not  contain  a  common  specialization  among  themselves. 
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This  allows  the  possibility  of  conflicting  inheritance  of 

values  and  structure. 

In  the  case  of  value  inheritance  there  may  be  a  set  of 
values  derived  from  immediate  ancestors  in  the  IS-A  hierarchy, 
all  of  which  are  eligible.  If  these  values  are  classes  the 
problem  is  avoided  if  a  member  of  the  set  is  a  specialization 
of  all  of  the  other  classes.  However,  if  the  values  are  not 
classes  or  if  there  is  no  common  specialization  of  a  set  of 
classes,  no  value  can  be  inherited.  In  such  cases  of  conflict, 
the  solution  presently  taken  by  PSN,  is  to  not  inherit  any 
value.  An  alternative  solution  is  available  when  the  IS-A 
hierarchy  is  extended  to  form  a  lattice  as  described  in 
[Schneider  1978a].  In  the  case  where  a  number  of  classes  are 
inherited,  the  final  value  for  the  slot  can  be  made  the  unigue 
meet  of  these  classes.  If,  however,  not  all  of  the  inheritable 
values  participate  in  the  IS-A  hierarchy,  no  value  is 
inherited. 

When  structure  is  inherited  from  a  number  of  superclasses, 
it  is  possible  that  two  or  more  versions  of  a  slot  will  be 
available.  Figure  2-7  illustrates  how  conflicting  versions  of 
a  slot  may  be  inherited.  The  slot  " raa jo r_pl ace_of_work"  is  the 
same  slot  in  each  place  it  occurs  although  the  properties  of 
each  version  are  slightly  different.  On  the  other  hand,  the 
slot  "number’9  in  "EMPLOYEE"  is  an  object  which  is  entirely 
unrelated  to  that  in  "STUDENT".  In  the  latter  case,  there  is 
no  problem  with  inheritance  within  the  formalism;  the  problem 
arises  when  one  attempts  to  reference  one  of  the  inherited 
slots  from  the  external  language,  and  how  it  is  handled  lies  In 
the  domain  of  such  a  language,  not  within  PSN.  In  English  for 
example,  one  could  distinguish  the  slots  by  qualifying  the  slot 
name  with  the  class  from  which  it  was  inherited.  Thus,  one 
might  say  ‘"number"  as  inherited  from  "EMPLOYEE"8  when  that  Is 
the  slot  one  is  referencing. 


On  the  other  hand,  PSN  must  handle  the  inheritance  of 
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figure  2-7 


figure  2-8 


II. 4  IS- A 


25 


conflicting  versions  of  the  same  slot.  A  version  of  a  slot  is 
known  as  a  redefinition  of  another  version  of  the  same  slot  if 
the  latter  version  is  part  of  the  structure  of  some  IS-A 
ancestor  of  the  class  whose  structure  contains  the  first 
version  and  some  modification  has  occurred  somewhere  between 
the  two  slots.  Thus  in  figure  2-3  "a"  in  "Al"  is  a 
redefinition  of  "a"  in  "A"  whereas  the  inherited  “a"  in  UA2"  is 
not.  Also,  since  the  version  of  "a"  in  ,,A2‘'  is  the  same  as 
that  in  "A”,  "a”  in  **  A 1 "  is  a  redefinition  of  na "  in  "A2”.  Now 
if  the  set  of  versions  of  a  slot  to  be  inherited  contains  a 
version  which  is  a  redefinition  of  all  the  other  versions,  that 
is,  there  is  a  unigue  redefinition.  this  version  can  be 
inherited  as  is  without  violation  of  the  IS-A  constraint. 

In  the  case  where  no  unigue  redefinition  is  contained  in 
the  inherited  set,  a  new  version  of  the  slot  must  be  created. 
This  situation  is  very  similar  to  that  of  value  inheritance  in 
that  there  is  a  set  of  values  to  be  inherited  by  a  version  of  a 
slot  for  each  of  the  properties  of  a  slot  (for  example  type 
etc.).  The  solution  is  also  the  same:  when  all  the  values 
participate  in  the  IS-A  hierarchy,  a  meet  class  may  be  created; 
otherwise  a  value  of  unknown  should  be  inherited. 

II. 5.  Relations 


The  slot  values  of  an  object  express  relationships  which 
are  considered  defining  properties  of  that  object.  Objects  may 
also  participate  in  relationships  that  are  more  incidental:  a 
man  may  have  a  wife,  but  being  an  instance  of  the  class  ’‘Men81 
does  not  require  that  an  object  has  a  wife.  Such  properties  of 
objects  are  known  as  assert ional  properties. 

In  PSN  a  class  of  objects  known  as  re lations  are  used  to 
define  relationships  between  objects.  For  example,  one  might 
define  a  relation  called  "  Husband-of which  can  be  used  to 
relate  instances  of  "Men"  to  instances  of  ‘'Women11.  A  specific 
pair  of  objects  are  related  through  an  assertion  which  is  an 
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instance  of  the  relation  object  describing  the  relationship. 
Thus  "John"  is  related  to  "Mary”  by  an  instance  of 
"Husband-of " .  In  this  case  '•John'’  is  the  source  of  the 
assertion  and  "Mary"  participates  as  the  target.  In  diagrams, 
the  connection  between  related  objects  is  an  arc;  this  arc  is 
associated  to  the  relation  either  by  passing  through  a  small 
circle  connected  to  the  relation  by  an  INST ANCE-QF  link,  or  by 
being  labelled  with  the  name  of  the  relation.  While  the  former 
expresses  more  clearly  the  flavour  of  the  formalism,  the  latter 
is  more  useful  because  it  avoids  adding  a  proliferation  of  arcs 
to  diagrams  which  are  already  very  complicated.  Figure  2-9 
illustrates  the  relation  "Husband-of "  and  the  assertion  between 
"John"  and  "Mary"  using  the  more  formal  notation. 

As  with  classes,  the  exact  meaning  of  a  relation  is 
provided  by  four  programs.  Their  functions  correspond  directly 
to  those  of  classes:  a  program  known  as  to-asser t  makes  the 
knowledge  that  two  objects  are  related  by  the  relation  part  of 
the  knowledge  base;  a  testing  program  decides  whether  the 
relation  holds  between  two  objects;  a  fetching  program  returns 
all  range  instances  of  the  relation  corresponding  to  some 
object  in  the  domain;  and  a  removing  program  is  used  to  destroy 
the  relation  instance. 

The  properties  by  which  programs  are  attached  to  relations 
are  defined  as  slots  in  the  class  "RELATION"  as  shown  in  figure 
2-10.  There  are  four  additional  property  values  attached  to 
relations  which  the  formalism  uses  to  provide  basic  constraints 
on  assertions.  The  "domain"  property  specifies  a  class  of 
which  any  object  participating  in  an  assertion  as  the  source 
must  be  a  instance.  The  "range"  property  specifies  a  class 
which  similarily  constrains  the  target  of  an  assertion.  A 
relation  is  then  a  map  from  the  "domain"  class  to  the  "range" 
class  where  the  test  program  decides  if  a  given  pair  of  objects 
is  a  member  of  the  relation. 

A  third  additional  property  is  the  "domain_inter val"  which 
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RELATION 


figure  2-9 


figure  2-10 
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is  an  interval  constraining  the  number  of  assertions  in  which 
any  object  in  the  domain  class  may  participate  as  the  source. 
The  interval  <i,j>  as  a  Mdomain_interval,,  indicates  that  each 
instance  of  the  domain  class  is  related  to  at  least  i  and  at 
most  j  objects  in  the  range  class.  For  example,  the  relation 
’’Age"  might  have  a  "doma in_interval"  of  <1,1>  indicating  that 
every  object  in  its  domain  must  have  a  unigue  age  (its  domain 
might  be  ”REAL_OB JECTS ’’ )  .  This  property  differs  from  a  slot 
"age"  in  the  domain  class  in  that  it  may  be  changed  at  any 
time. 


Corresponding  to  the  "domain_interval"  (usually  called 
"d_int")  is  the  property  "range__interval "  ("r_int")  which 
provides  similar  constraints  on  the  number  of  assertions  in 
which  an  instance  of  the  range  class  may  participate  as  the 
target. 

It  is  natural  to  allow  a  specialization  relation  between 
relations,  and  PSN  allows  IS-A  to  relate  two  such  objects.  The 
meaning  of  IS-A  can  be  adopted  without  change:  an  assertion  is 
an  instance  of  all  superclasses  of  any  relation  of  which  it  is 
an  instance,  and  relations  inherit  values  from  their 
superrelations.  (Relations  will  in  general  not  have  internal 
structure)  .  In  most  cases,  specialization  of  a  relation 
reguires  the  specialization  of  one  or  more  of  the  eight 
property  values.  A  simple  example  is  restriction  of  a 
relation,  where  a  subrelation  in  which  the  domain  is  a  subclass 
of  the  inherited  domain  would  be  the  restriction  of  the 
original  relation  to  the  new  domain. 


In  PSN  intervals  are  not  represented  as 
Therefore,  one  can  again  not  insist  that  the  propert 
relation  be  IS-A  descendants  of  the  inherited  values 
it  is  natural  to  consider  a  more  restricted 
specialization  of  a  more  general  interval,  that  is, 
end  of  the  specialized  interval  is  greater  than 
parent,  and  the  higher  end  is  less  than  that  of  t 


classes, 
y  values  of 
.  However, 
interval  a 
the  lower 
that  of  its 
he  parent. 
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Thus  <3,5>  is  a  specialization  of  <1,8>.  It  is  necessary  for 
the  maintenance  of  consistency  in  the  knowledge  base  that  the 
intervals  of  a  subrelation  be  specializations  of  the  inherited 
intervals  in  this  way. 


CHAPTER  III 


Metastructure  and  Programs 


111 . 1 .  Introduction 

Since  programs  play  a  large  role  in  PSN,  it  is  useful  to 
provide  structuring  tools  which  may  help  in  the  understanding 
of  these  objects.  In  particular  one  would  like  a  declarative 
representation  of  programs  which  interacts  with  IS-A  to  provide 
a  means  of  specialization.  The  approach  taken  is  that  of  TAXIS 
[Wong  1980]  in  which  the  statements  of  a  program  are 
represented  as  properties  of  slots  in  a  class.  This  approach 
requires  that  slots  be  differentiated,  hence  the  concept  of 
raeta structure  is  introduced  in  section  two. 

Section  three  will  discuss  the  structure  of  programs  and 
the  following  sections  will  discuss  the  dynamic  environment  and 
the  handling  of  exceptions. 

111. 2.  Metastructure 

In  chapter  two,  the  structure  of  a  class  was  defined  to  be 
a  set  of  objects  which  define  the  properties  which  an  instance 
of  the  class  may  have.  This  section  proposes  a  mechanism  by 
which  these  slots  may  be  organized.  What  results  are  objects 
which  provide  categories  of  slots  just  as  classes  provide 
categories  of  objects.  In  addition  the  mechanism  will  allow 
the  definition  of  new  categories  of  slots  which  have  properties 
in  addition  to  the  standard  "type",  ‘’default",  and 
"restriction".  A  use  for  such  additional  properties  is  found 
in  the  representation  of  programs.  Finally,  the  new  mechanism 
provides  a  means  for  restricting  the  number  of  slots  of  a  given 
category  which  may  appear  in  a  class. 
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This  mechanism  might  be  applied,  for  example,  in  the 
definition  of  a  metaclass  known  as  “PHYLUM"  as  part  of  a 
taxonomy  of  animals.  A  category  of  slots  which  must  appear  in 
each  instance  of  this  metaclass  is  a  body  part;  for  example  the 
class  "ARTHROPODA"  would  define  the  property  “thorax"  because 
each  instance  of  this  class  would  have  a  thorax.  Restrictions 
on  the  set  of  body  part  slots  might  be  that  each  instance  of 
“PHYLUM"  must  define  at  least  one  body  part,  and  that  the  type 
property  of  a  body  part  slot  have  as  value  a  class  of  body 
parts.  Thus  the  type  of  the  slot  “thorax"  would  be  the  class 
“THORAX"  which  has  as  instances  all  individual  thoraxes. 

The  solution  begins  by  introducing  the  solution  to  a  loose 
end  left  in  chapter  two.  There  it  was  pointed  out  that  no 
class  had  been  introduced  which  provided  a  part  of  which  “slot" 
might  be  an  instance.  If  it  is  made  an  instance  of  itself  as 
is  “CLASS",  it  would  require  for  itself  values  for  the 
properties  "type",  "restriction",  and  "default".  The  meaning 
of  such  values  is  not  clear.  In  addition,  "slot"  would  be 
treated  differently  from  its  other  instances,  for  the  other 
instances  of  "slot"  are  slots  whereas  "slot"  cannot  be 
considered  a  slot. 

The  alternative  is  to  introduce  a  new  class  of  which 
"CLASS"  is  an  instance  as  shown  in  figure  3-1.  This  is  the  new 
class  called  "METACLASS"  whose  instances  are  all  metaclasses 
and  include,  in  particular,  the  metaclasses  "CLASS"  and 
"METACLASS".  These  two  classes  are  instances  of  "CLASS"  (as 
required)  because  they  are  instances  of  a  subclass  of  "CLASS", 
namely  "METACLASS".  Since  a  metaclass  is  a  class  whose 
instances  are  classes,  all  metaclasses  must  ensure  that  their 
instances  are  in  fact  classes.  The  simplest  way  to  enforce 
this  is  by  requiring  that  all  instances  of  "METACLASS"  be 
subclasses  of  "CLASS".  This  is  necessary  also  because 
instances  of  metaclasses  may  contain  slot  definitions  only  if 
the  metaclass  contains  "slot"  which  it  may  acguire  only  through 
inheritance  along  IS-A.  In  the  other  direction,  any  subclass 
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of  '’CLASS'*  whose  instances  are  to 
an  instance  of  "METACLASS"  so 
inherited. 


have  structure 
that  "slot" 


must  be  made 
may  be  validly 


"slot"  is  now  an  instance  of  "metaslot"  which  is  an 
instance  of  "METACLASS"  and  therefore  a  subclass  of  "CLASS"  and 
hence,  since  it  is  an  instance  of  itself,  an  instance  of 
"CLASS".  Instances  of  "metaslot",  or  metaslots .  are  classes 
whose  instances  are  slots  and  therefore  impose  constraints  on 
and  supply  structure  to  these  slots.  Figure  3-2  illustrates  an 
example  of  such  a  metaslot.  Here  it  has  been  decided  that 
instances  of  the  metaclass  "PHYLUM"  should  have  slots  which 
describe  various  body  parts  and  that  the  types  of  these  slots 
be  limited  to  instances  of  the  metaclass  "BODY-PART-CLASS". 
This  is  done  through  the  definition  of  the  metaslot 
"body-part",  which  because  it  is  a  subclass  of  "slot"  will 
inherit  the  properties  of  "slot".  In  particular,  its  instances 
will  be  slots,  and  its  structure  will  contain  the  slot  "type" 
for  which  the  type  is  modified.  Now  slots  in  any  instance  of 
"PHYLUM"  (for  example,  " ARTHROPODA" )  may  be  made  instances  of 
the  new  metaslot,  suffering  however  the  additional  restriction 
on  their  type  links. 


It  must  be  emphasized  that 
figure  3-2  is  a  slot  of  the  class 
"PHYLUM".  Hence,  this  slot  c 
instances;  for  example,  the  type 
an  instance  of  "BODY- PAR T-CLAS 
value  of  "body-part"  is  <1,*>,  th 
of  "PHYLUM"  have  at  least  one  i 
is  used  to  represent  an  infinite 
the  case  in  the  class  "ARTHROPODA 


the  slot  "type"  ill 
"body-part",  not  o 
onstrains  the  typ 
of  the  slot  "thorax 
S".  The  "interva 
us  requiring  that  a 
nstance  of  this  cla 
upper  bound) ,  as 
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"metaslot"  contains  within  itself  the  slot  "interval". 
The  value  of  "interval"  for  a  metaslot  constrains  the  number  of 
instances  of  that  metaslot  which  may  be  PART-OF  any  individual 
instance  of  the  defining  metaclass.  In  figure  3-2,  the 
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interval  <1,*>  for  "body-part”  means  that  each  instance  of 
"PHYLUM"  must  have  at  least  one  body  part.  The  interval  on 
"metaslot"  is  of  course  <0,*>  allowing  any  number  of  raetaslots 
in  any  metaclass. 

Only  if  a  metaslot  is  a  subclass  of  "slot"  will  the 
instances  of  the  metaslot  be  slots.  Since  PSN  has  no  use  (at 
present) ,  for  objects  which  are  part  of  classes  which  are  not 
either  slots  or  metaslots,  the  add  program  of  "metaslot"  will 
force  its  instances  to  become  subclasses  of  "slot"  or  of 
"metaslot".  These  subclasses  of  "slot"  form  a  subset  of  the 
structure  of  a  class  which  is  known  as  the  metastructure. 

"METACLASS"  is  a  metaraetaclas s  because  its  instances  are 
metaclasses  and  "raetaslot"  is  similarly  a  metametaslot.  This 
has  added  explicitly  this  additional  layer  of  the  INSTANCE-OF 
levels  which  was  previously  only  implicit.  Higher  levels  are 

still  possible  because  "METACLASS"  is  an  instance  of  itself  - 

other  metametaclasses  can  be  defined  as  IS-A  descendants  of 
this  class,  and  if  instances  of  a  subclass  of  "METACLASS"  are 
also  metametaclasses  one  has  a  class  on  a  higher  level.  This 
can  of  course  be  continued  indefinitely.  The  same  thing  is 
possible  with  "metaslot". 

The  notation  thus  far  given  for  the  definition  of 
metaslots  and  the  association  of  slots  with  their  parent 
instances  is  far  too  cumbersome  to  use  in  most  diagrams. 
Figure  3-3  illustrates  the  shorthands  which  are  used  for  these 
two  cases:  any  object  drawn  as  a  box  within  a  box  will 
represent  a  metaslot,  thus  be  assumed  an  instance  of 
"metaslot".  In  instances  of  a  metaclass,  the  slots  will  be 
grouped  in  a  list  under  the  metaslot  names.  If  no  metaslot 
names  are  indicated,  it  is  to  be  assumed  that  the  slot  is 
simply  an  instance  of  slot.  Thus  "MCI"  is  a  metaclass  in  which 
the  metaslots  "msl"  and  "ms2”  are  defined,  and  in  the  class 
"Cl",  "e"  is  an  instance  of  "slot"  only  while  "a",  "b",  and  "c" 
are  instances  of  "msl"  and  "d"  is  an  instance  of  "ms 2". 
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MCI 


figure  3-3 
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III. 3.  Programs 

III. 3.1  Introduction 

The  association  of  programs  with  classes  Is  a  major 
defining  characteristic  of  PSN.  This  association  is 
accomplished  through  the  mechanism  for  associating  property 
values  with  objects  and  assumes  that  programs  are  objects 
existing  in  the  knowledge  base.  The  next  step  is  to  involve 
these  objects  in  the  network  in  a  way  which  allows  the 
structure  of  programs  to  provide  an  indication  of  their 
functions  and  allows  a  declarative  means  of  relating  theme 

The  need  for  relating  programs  results  from  the  IS-A 
hierarchy  of  classes:  the  relations  between  programs  in  the 
network  will  constrain  what  programs  may  be  associated  with 
IS-A  related  classes.  Thus  if  "STUDENT"  IS-A  "PEBSON",  the 
programs  for  "PEBSON"  must  be  IS-A  parents  of  the  programs  for 
"STUDENT".  The  following  paragraphs  will  consider  the 
relationships  that  IS-A  between  classes  imposes  on  the  four 
programs  of  each  class. 

When  the  add  program  for  a  class  is  executed,  some  change 
in  the  knowledge  base  will  occur  which  indicates  that  an  object 
is  now  an  instance  of  the  class.  For  example,  an  assertion  of 
some  relation  may  be  created.  A  change  in  the  knowledge  base 
caused  by  the  execution  of  a  program  is  called  a  side  effect. 
However,  only  the  lasting  side  effects  resulting  from  the 
execution  of  a  program  are  significant.  An  action  which  is  not 
lasting  might  be  the  creation  of  an  object  which  is  destroyed 
later  in  the  execution  of  the  program.  The  effects  that  remain 
after  the  execution  of  the  program,  that  is,  the  differences 
between  the  state  of  the  knowledge  base  before  execution,  and 
the  state  after  execution,  are  known  as  the  net  side  effects. 

When  IS-A  is  holds  between  two  classes,  any  instance  of 
the  subclass  must  be  an  instance  of  the  superclass.  If  the 
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actions  involved  in  making  an  object  an  instance  of  the 
subclass  include  all  the  actions  which  would  have  been 
performed  in  making  the  object  an  instance  of  the  superclass 
alone,  the  to-test  and  to-fetch  programs  of  the  superclass  must 
surely  recognize  that  object  as  an  instance  of  that  class. 
Thus  if  the  set  of  net  side  effects  of  an  add  program  for  a 
class  is  a  subset  of  the  net  side  effects  of  another  program, 
the  latter  program  can  be  the  add  program  for  a  subclass. 

The  net  side  effects  of  a  program  may  include  deletions  of 
objects  and  assertions.  If  the  net  side  effects  of  the  to-kill 
program  of  a  class  form  a  subset  of  those  of  the  to-kill 
program  for  a  subclass,  removing  an  object  from  the  subclass 
will  necessarily  remove  the  object  from  the  superclass.  Thus 
restricting  the  programs  in  this  way  will  insure  that  the 
subclass  is  indeed  a  valid  specialization. 

The  test  program  of  a  class  is  not  allowed  to  have  net 
side  effects.  There  is,  however,  a  relationship  between  the 
values  returned  by  such  programs  for  IS-A  related  classes.  In 
particular,  for  an  object  which  is  an  instance  of  the  subclass, 
the  test  programs  of  both  classes  must  return  true.  If  the 
object  is  not  a  member  of  the  subclass,  the  test  program  for 
the  subclass  must  return  false,  but  that  of  the  superclass  may 
return  either  true  or  false.  If  the  object  is  not  a  member  of 
the  superclass,  it  cannot  be  a  member  of  the  subclass.  Hence 
the  relationship  between  the  values  returned  by  the  two 
programs  is  logical  implication:  the  result  returned  by  a  test 
for  membership  of  a  subclass  implies  the  result  for  the 
superclass . 

Finally,  one  must  consider  the  fetch  programs  of  classes. 
Fetch  programs  are  generators .  programs  whose  executions 
suspend  themselves  to  return  a  value  and  then  may  be 
reactivated  to  return  another  value.  A  fetch  program  would 
therefore  return  one  instance  of  the  class  for  each 
reactivation  until  the  members  of  the  class  are  exhausted  and 
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the  program  terminates.  When  one  considers  the  execution  of  a 
generator  as  the  period  from  the  first  activation  until  the 
termination,  such  a  program  will  have  no  net  side  effects.  In 
addition,  the  value  returned  when  the  program  terminates  should 
be  an  indication  to  the  calling  program  that  termination  has 
occurred,  not  a  member  of  the  class.  Therefore,  the 
relationship  between  fetch  programs  of  IS-A  related  classes 
will  not  be  characterized  by  restrictions  on  either  the  net 
side  effects  or  the  value  returned. 

The  above  discussion  has  indicated  how  a  relation  between 
programs  must  restrict  their  net  side  effects  and  values 
returned  if  this  relation  is  to  indicate  when  a  program  might 
be  used  as  one  of  the  four  programs  of  a  subclass  of  some 
class.  In  PSN  programs  are  represented  as  classes  ana  this 
relation  between  programs  is  IS-A.  Therefore,  if  one  program 
is  to  be  a  specialization  of  another,  the  structures  of  the  two 
programs  must  be  related  as  constrained  by  the  inheritance 
rules  described  in  chapter  two.  Inheritance,  however,  is  not 
sufficient  to  insure  that  two  IS-A  related  programs  attached  to 
IS-A  related  classes  will  act  in  the  reguired  manner. 
Therefore,  for  a  program  "pi”  to  be  a  legal  specialization  of 
Mp2"  it  is  necessary  that  when  run  in  identical  knowledge  bases 
with  the  same  parameters 

1.  If  the  programs  return  boolean  values  then  the  value 
returned  by  "pi"  must  logically  imply  the  value  returned 
by  Mp2M.  If  the  programs  do  not  return  boolean  values, 
they  must  return  identical  values. 

2.  The  set  of  net  side  effects  of  np2n  must  be  a  subset  of 
the  net  side  effects  of  "pi" .  This  means  that  the 
specialization  must  perform  at  least  the  changes  done  by 
"p2M.  "pi"  is  not  a  legal  specialization  if  it  performs 
the  same  actions  as  "p2M  and  then  proceeds  to  perform 
other  actions,  some  of  which  undo  those  performed  in  the 
first  phase. 

When  "p2n  is  specialized  to  f,p1" ,  it  is  possible  to  restrict 
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the  domain  for  which  the  program  returns  values;  the  above 
definition  must  hold  only  if  the  specialization  executes 
successfully  in  a  given  state®  Although  the  structural 
constraints  imposed  by  IS-A  on  the  specialization  of  programs 
is  not  sufficient  to  produce  legal  specializations,  the 
mechanism  does  encourage  the  correct  definition  of  IS-A  related 
programs  and  makes  it  possible  to  specify  guide  lines  for 
proper  specialization. 

III. 3.2  The  Structure  of  Programs 

The  basic  declarative  objects  of  a  program  are  the 
parameters  and  variables,  and  the  statements.  If  these  behave 
like  slots  in  a  class  in  inheritance,  one  has  immediately  new 
tools  for  specializing  programs.  For  example,  the  types  of 
parameters  will  be  the  types  of  slots.  Then  to  specialize  a 
program  one  can  specialize  the  types  and  possibly  contribute 
more  parameters.  In  a  similar  fashion,  one  might  want  to 
specialize  the  actions  of  individual  statements,  or  add  new 
statements  which  will  add  to  the  set  of  actions  performed  by 
the  program. 

In  PSN  all  programs  are  classes,  and  parameters, 
variables,  and  statements  are  represented  by  slots.  The 
various  roles  of  slots  are  distinguished  by  the  metaslots  of 
which  they  are  instances:  parameters  are  instances  of  the 
metaslot  "parameters".  The  metaslot  tool  is,  in  addition,  used 
to  add  more  structure  to  programs  by  dividing  the  evaluatable 
slots  into  three  groups;  the  prerequisites  are  predicates,  all 
of  which  must  return  true  before  program  execution  begins;  the 
bochy  containing  statements  which  perform  the  actions  of  the 
program;  and  the  returns  statement  which  computes  a  final  value 
to  be  returned. 

Figure  3-4  illustrates  the  structure  of  the  metaclass 
"PROGRAM "  of  which  all  programs  must  be  instances.  The 
metaslots  of  "PROGRAM"  can  be  divided  into  two  categories: 
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"parameters”,  "body",  "prerequisites",  and  "returns"  are  those 
which  the  user  uses  to  group  his  statements  when  writing  the 
program,  while  the  remainder  are  used  to  introduce  the  new 
properties  which  the  slots  of  a  program  require.  Thus  any  slot 
of  the  body  of  a  program  will  have  the  properties  "eval", 
"exception_action" ,  and  "exception"  having  types  "FORM", 
"EXCEPTI  ON_HANDLER_LINK" ,  and  "  EXCEPTIONAL  A  SSES  "  respectively. 
The  IS- A  hierarchy  of  metaslots  within  "PROGRAM"  arises  from 
the  need  to  give  the  "eval"  property  to  each  of  the  "body", 
"prerequisites",  and  "returns"  metaslots  with  slightly 
different  definitions.  Thus  "eval"  has  the  same  meaning  for 
both  a  "returns"  slot  and  a  "body"  slot,  but  the  property  value 
associated  with  the  "returns"  slot  must  be  an  "EXPRESSION", 
while  that  associated  with  the  "body"  slot  must  be  a  "FORM". 

The  important  innovation  which  makes  programs  executable 
is  the  "eval"  property  which  "body",  "prerequisites",  and 
"returns"  slots  may  now  have.  The  type  of  the  "eval"  property 
is  the  class  "FORM"  or  some  subclass  of  this  class.  Instances 
of  "FORM",  known  as  forms ,  are  used  to  invoke  other  programs. 
The  forms  used  for  "prerequisites"  and  "returns"  slots  must  not 
have  side  effects.  Instances  of  the  classes  "EXPRESSION"  and 
" BOOL EAN_EX?RESS ION"  are  forms  which  call  programs  without  side 
effects.  Additional  restrictions  on  the  statements  of  programs 
are  that  prerequisite  slots  must  be  of  type  "BOOLEAN"  (the  only 
instance  of  the  class  " BOOL EAN_C LASSES")  and  there  must  be 
exactly  one  "returns"  slot  (all  programs  return  values) . 

As  mentioned  above,  the  value  of  the  "eval"  property  is  a 
form :  this  is  a  PSN  object  which  can  be  interpreted  to  produce 
a  value.  When  the  structure  of  a  form  is  not  important,  it  is 
represented  in  diagrams  by  code  in  the  PSN  language  enclosed  in 
square  brackets  £"[ ]") .  A  particular  example  of  a  form  is 
"[slot-name]"  which  means  use  the  value  of  the  slot  with  name 
"slot-name"  when  the  form  is  interpreted.  In  the  context  of 
inheritance,  it  is  important  to  note  that  forms  too  are  classes 
and  hence  specialize  through  IS-A.  Figure  3-5  shows  how  a 
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program  to  compute  the  factorial  of  its  parameter  might  be 
represented.  This  program  has  one  parameter,  ”n”.  The 
prereguisite  ”n_positive”  checks  that  the  value  bound  to  "n"  is 
greater  than  0.  If  this  is  the  case,  execution  proceeds  with 
the  interpretation  of  the  form  associated  with  the  body  slot 
’’compute”.  when  the  value  is  returned,  it  is  bound  to 
’’compute”  in  the  same  way  that  the  actual  parameter  value  is 
bound  to  ”n”.  Thus  the  value  to  be  returned  is  computed  by 
finding  the  value  bound  to  ’’compute”. 

Execution  of  a  program  involves  creating  an  instance, 
known  as  a  process ,  of  the  class  and  then  computing  values  for 
all  its  slots.  The  value  associated  with  the  returns  slot 
becomes  the  value  to  be  returned.  Initially,  the  form  invoking 
the  program  supplies  the  values  of  the  parameters  properties  of 
this  process  using  a  mechanism  which  will  be  described  in  the 
next  section.  The  values  For  the  slots  of  a  process  are  the 
values  of  the  returns  slots  of  the  processes  created  when  the 
form  associated  with  a  slot  is  interpreted.  The  evaluation  of 
the  slots  is  divided  into  three  groups:  first  the 
prerequisites,  then  the  slots  of  the  body,  then  the  returns 
slot.  The  execution  of  the  program  will  fail  should  any  of  the 
prereguisite  slots  be  assigned  the  value  false. 

Within  each  of  these  groups,  the  order  of  execution  is  not 
predetermined;  the  mechanism  for  accessing  the  slots  is  through 
the  ”to-fetch”  programs  of  the  metaslots;  thus  to  acquire  all 
the  prerequisites  of  a  program  ”p1”  the  operation  is  to  fetch 
all  instances  of  the  metaslot  ’’prerequisites ”  which  are  PART-OF 
the  class  ”p1”.  This  lack  of  order  has  no  major  consequences 
when  the  slots  being  executed  have  no  side  effects  as  in  the 
case  of  prerequisites.  However,  the  consequences  for 
statements  in  the  body  are  rather  severe:  the  side  effects  of 
any  one  statement  must  be  independent  of  those  of  the  other 
statements.  As  a  concrete  example,  consider  a  case  where  one 
statement  creates  an  object  and  another  asserts  that  this 
object  is  related  to  some  other  object  through  some  relation. 
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Since  the  order  of  execution  is  not  guaranteed,  it  is  possible 
that  the  assertion  would  be  attempted  before  the  creation,  a 
situation  which  must  surely  result  in  some  sort  of  error. 

When  a  program  is  specialized  using  IS-A,  the  programmer 
will  be  constrained  by  this  lack  of  order  to  add  only 
statements  which  are  independent  of  those  inherited.  This 
implies  that  the  new  statements  cannot  act  to  undo  the  effects 
of  the  inherited  statements,  thus  the  new  program  must  become  a 
legal  specialization.  However,  as  will  be  explained  later,  the 
inherited  statements  may  be  modified  in  a  way  which  will  cause 
illegal  specializations. 

III. 3. 3  Forms 

The  objects  which  are  the  "eval"  property  values  of  the 
statement  slots  of  a  program  are  called  forms .  A  form  is 
defined  recursively  as 

1.  a  reference  to  a  slot; 

2.  a  subclass  of  a  program  and  an  instance  of  the  class 
’’FORM”  in  which  all  parameters  slots  have  either  "eval" 
property  values  which  are  forms,  or  "quote"  property 
values. 

The  relationship  between  forms  and  programs  is  like  that  of 
LISP;  forms  are  expressions  and  programs  correspond  to  lambda 
expressions  (functions)  .  The  parameters  slots  of  a  program 
provide  a  means  for  binding  the  free  variables  in  the  forms 
invoked  by  the  program. 

This  concept  of  forms  provides,  as  it  does  for  programs,  a 
handle  on  the  internal  structure  and  a  declarative  meaning  for 
specialization.  It  is  here  that  the  PSN  description  of 
programs  differs  most  from  that  of  TAXIS  [Wong  1980].  The 
definition  of  programs  is  very  similar  to  that  of  TAXIS 
transactions ,  but  in  TAXIS  the  objects  corresponding  to  forms 


are  expressions  which  are  simply  non-decomposable  objects  which 
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Figure  3-6  shows  the  notations  used  to  show  the  complete 
structure  of  forms.  The  program  "SQUARE"  computes  the  square 
of  its  parameter  by  invoking  a  form  which  calls  the  program 
"TIMES".  The  parameters  of  "TIMES"  will  both  be  bound  to  the 
value  of  the  parameter  "x"  of  "SQUAFE".  If  a  form  is  a  slot 
reference,  the  arc  labelled  "eval"  is  drawn  to  the  appropriate 
object.  Other  forms  are  simply  drawn  as  classes.  The  form 
"FT"  (representing  "[times  x,x]")  demonstrates  the  advantages 
of  making  a  form  a  subclass  of  the  program:  the  parameters  are 
passed  to  the  form  by  the  regular  inheritance  mechanism,  and 
binding  them  to  other  forms  involves  only  the  addition  of  the 
"eval"  values.  Forms  are,  however,  additionally  distinguished 
from  programs  by  having  among  their  types  the  class  "FOF.M ". 

This  declarative  mechanism  allows  forms  to  be  specialized 
in  two  ways.  The  first  is  by  using  IS-A  descendants  of  the 
forms  to  which  the  parameters  are  bound.  The  second  is  through 
the  specialization  of  the  program  which  the  form  calls.  In 
this  case  it  is  necessary  to  explicitly  make  the  new  form  an 
IS-A  descendant  of  both  the  old  form  and  the  specialized 
program.  Figure  3-7  shows  the  specialization  of  a  form  in 
which  the  specialized  form,  that  associated  with  "a"  in  "P3", 
involves  a  call  to  a  specialization  of  the  program  used  in  the 
IS-A  parent. 

When  a  form  is  executed,  a  corresponding  process  is 
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figure  3~7 


figure  3-8 
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Some  parameters  slots  will  be  instances  of  the  metaslot 
"quote_parameters" ,  having  "quote"  links  instead  of  "eval" 
links.  In  these  cases  the  parameter  assignment  involves  only 
the  assertion  that  the  parameter  value  is  the  value  of  the 
"quote"  property  of  the  slot.  One  use  of  this  type  of 
parameter  is  in  a  form  which  Is  a  call  to  the  identity  function 
in  which  the  single  parameter  is  a  quoted  parameter.  This 
produces  the  effect  of  the  LISP  QUOTE,  as  in  the  form  "  (QUOTE 
X)  ". 

The  "dynamic"  relation  is  important  in  the  evaluation  of 
forms  which  reference  slots;  to  evaluate  a  slot,  the 
interpreter  searches  back  along  the  "dynamic"  arcs  until  a 
process  is  found  which  is  an  instance  of  a  program  of  which  the 
slot  is  a  part.  The  value  returned  is  then  simply  the 
corresponding  slot  value.  This  mechanism  results  in  the  usual 
interpretation  of  parameters  and  variables  in  recursion;  the 
values  found  will  be  those  most  recently  bound.  Figure  3-8 
shows  a  point  in  the  evaluation  of  the  form  "[eval  square  with 
x<-2]’’  with  the  program  "square"  as  illustrated  in  3-6.  Here 
the  process  which  is  an  instance  of  the  program  "TIMES"  has 
finished  execution,  but  is  still  joined  to  the  calling  process 
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by  "dynamic”  and  the  returning  value  has  not  yet  been  linked. 
More  specificly,  the  execution  of  the  form  "FT"  will  have  begun 
with  the  creation  of  the  un labelled  process.  The  "eval" 
property  values  of  the  slots  "ax"  and  "ay"  is  the  slot  "x", 
therefore  in  parameter  evaluation,  the  value  assigned  to  each 
of  the  properties  "ax"  and  "ay"  is  the  value  of  the  property 
"x"  of  the  calling  process,  "pOIII".  Subsequently,  the  "eval" 
property  of  the  "returns"  slot,  "prim"  of  "FT"  is  evaluated. 
This  is  a  primitive  function  which  computes  the  product  of  the 
two  parameters  and  returns  a  value  which  then  becomes  the  value 
of  the  "prim"  property  of  the  process.  The  next  stage  in 
interpretation  involves  asserting  that  "4"  is  the  value  of  the 
"r"  property  of  "pOIII".  Once  the  value  has  been  returned  in 
this  way,  the  "dynamic"  assertion  will  be  removed  and  the 
instance  of  "FT"  will  be  killed. 

Since  the  variable  bindings  are  associated  with  slot 
objects  which  are  referenced  in  the  structure  of  the  programs, 
the  scope  of  the  variables  is  static  (fixed  at  the  time  of 
creation  of  the  program) .  A  slot  of  the  same  name  in  two 
unrelated  programs  will  be  entirely  different  objects,  and  a 
form  referencing  one  will  never  acquire  the  value  from  a 
process  which  is  an  instance  of  the  program  containing  the 
other.  One  effect  of  this  is  that  forms  are  tightly  bound  to 
the  programs  of  which  they  are  statements;  an  arbitrary  form  is 
not  likely  to  be  useful  in  more  than  one  program  because  the 
slots  which  are  referenced  are  not  related* 

Once  the  parameters  are  evaluated,  execution  proceeds  as 
described  in  the  previous  section.  A  program  called  normally 
will  execute  to  completion.  The  interpreter  will  then  find  the 
returned  result  and  bind  it  to  the  appropriate  slot  of  the 
calling  process.  At  this  point,  the  terminated  process  will  be 
killed. 

There  is  a  second  mechanism  for  invoking  programs  which 
provides  a  coroutine  mechanism.  A  process  may  temporarily 
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suspend  execution  and  return  a  value  through  a  detach 
operation,  which  saves  the  state  of  the  process,  computes  a 
value  to  be  returned  and  places  an  instance  of  "DETACH”  into 
the  dynamic  chain  in  the  position  of  the  original  process. 
Thus  the  calling  process  acquires  a  value  and  kills  a  process 
as  is  normally  done,  but  the  original  process  remains  and  may 
be  restarted  by  any  other  process  knowing  the  identity  of  the 
detached  object.  When  such  a  process  returns  a  new  object  in  a 
class  or  a  relation  each  time  it  is  invoked  until  all  such 
objects  are  exhausted,  it  is  known  as  a  generator. 

III.  3.4  Sequential  Program  Constructs 


A  previous  section  has  described  the  non-de terministic 
evaluation  of  the  statements  of  a  program;  it  was  pointed  out 
that  this  forces  a  programmer  to  specialize  programs  in  the 
desired  way.  It  is,  however,  not  clear  that  all  desirable 
programs  may  be  written  with  this  mechanism.  In  any  case,  it 
is  possible,  using  only  the  mechanisms  illustrated  so  far,  to 
create  a  sequence  of  forms  which  must  be  executed  sequentially. 


Figure  3-9  illustrates  a  program  of  two  arguments  known  as 
"BEGIN" .  Its  first  parameter  may  be  any  object,  the  second 
must  be  a  form.  If  the  second  parameter  is  identical  to  an 
object  known  as  "NULL_FORM",  the  program  will  return  the  value 
of  the  first  parameter,  otherwise  it  will  return  the  result  of 
evaluating  the  second  parameter.  "NULL_F0RM"  is  a  form  which 
is  a  subclass  of  " NULL_PROGRAH" .  This  is  a  class  entirely 
without  structure,  hence  evaluation  in  any  domain  will  have  no 
net  side  effects,  and  the  returned  value  will  always  be 
unknown.  Therefore,  any  program  may  be  a  specialization  of 
"NULL_PROGRAM"  and,  hence,  any  form  a  specialization  of 
"NULL_F0RM". 

Figure  3-10  shows  a  chain  of  forms  which  are  subclasses  of 
"BEGIN"  joined  together  by  "quote"  links.  The  "argl" 
parameters  have  as  their  "eval"  properties  another  set  of 
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figure  3-9 


BEGIN 


52 


III . 3  Programs 


forms.  Until  the  last  "BEGIN”  form  is  reached,  the  sequence  of 
operations  will  be  {for  each  "BEGIN"): 

1.  create  the  process  and  associate  the  parameters 

properties;  the  "argl"  property  value  will  be  found  by 
evaluating  the  form  which  is  its  "eval"  property;  the 
"arg2"  property  value  is  simply  the  "quote"  property 

2.  the  narg2"  property  value  will  be  interpreted. 

This  mechanism  then,  allows  the  guaranteed  sequential 
evaluation  of  the  forms  associated  with  the  "argl"  properties 
of  the  "BEGIN"  forms.  Thus,  in  the  example  of  figure  3-10,  the 
form  "FI"  will  always  be  interpreted  before  "F2",  and  "F3"  will 
be  executed  last. 

This  sequence  of  forms  has  another  interesting  property. 
Since  any  form  may  be  a  valid  specialization  of  "NULL_FORN" ,  a 
specialization  of  the  last  "BEGIN"  form  in  the  sequence  may  be 
made  by  replacing  the  "quote"  property  by  another  "BEGIN"  form. 
This  specialization  can  then  be  made  the  "quote"  property  value 
of  "arg2"  in  the  previous  form.  The  process  may  be  continued 
up  to  a  program  definition  as  shown  in  figure  3-11.  What  has 
resulted  here  is  a  specialization  of  program  by  the  addition  of 
a  form  at  the  end  of  a  group  of  forms  which  are  sequentially 
executed.  This  structure  of  "BEGIN"  forms  Is  the  means  by 
which  a  "begin  -  end"  block  may  be  implemented  in  ?SN. 

This  structure,  of  course,  makes  it  possible  once  again, 
to  create  IS-A  children  of  a  program  which  are  not  legal 
specializations.  For  example,  when  creating  the  program  "P2" 
in  figure  3-11,  the  programmer  could  specify  an  "F3"  which 
would  undo  a  side  effect  caused  by  "FI"  or  "F2".  It  is  the 
responsibility  of  the  programmer  to  avoid  doing  so. 

In  summary,  the  rules  for  producing  legal  specializations 
of  programs  are 
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of  those  associated  with  the  other  slots,  and 

2.  avoid  the  addition  of  forms  at  the  end  of  begin  blocks 
which  cancel  the  actions  of  inherited  forms. 


III. 4.  Exceptions 

At  times  in  the  execution  of  a  PSN  command  one  finds  that 
execution  can  not  continue  because  some  constraint  or 
prerequisite  is  not  satisfied.  Such  an  occurrence  is  known  as 
an  exception.  There  are  two  types  of  exceptions  which  can 
arise  in  the  PSN  formalism.  One  type  arises  from  an 
inconsistency  in  the  state  of  the  knowledge  base;  for  example, 
an  object  having  a  slot  value  which  violates  a  restriction  on 
the  slot  would  be  exceptional.  Exceptional  objects  might  be 
allowed  in  the  knowledge  base  if  their  existence  is  explained 
by  an  object  known  as  an  excuse.  The  handling  of  such 
exceptions  is  discussed  in  detail  in  [Lesperance  1980]. 

The  second  type  of  exception  is  the  dynamic  exception  in 
the  execution  of  programs.  In  programming  languages  an 
exception  arises  when  some  illegal  action,  such  as  division  by 
zero,  occurs  during  execution.  The  usual  action  is  to  set  a 
flag  describing  the  exception,  aborting  the  routine  in  which 
the  exception  occurred,  and  activating  a  special  block  of  code, 
known  as  an  exception  handler ,  in  the  calling  routine.  The 
exception  handler  will  compute  a  value  which  is  to  be  returned 
as  the  value  for  the  routine  which  failed.  For  example,  a 
routine  for  division  will  usually  fail  when  the  divisor  is 
zero;  in  this  case  the  division  is  aborted  and  a  flag  for  a 
"zero-divide"  exception  is  set.  This  is  known  as  raising  the 
exception.  The  calling  routine  may  contain  an  exception 
handler  for  this  exception  which  might  decide  that  the  value  of 
the  division  should  be  zero.  A  different  calling  routine  might 
contain  a  different  handler,  one  that  decides  that  the  value 
should  be  that  of  the  largest  representable  number.  The 
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exception  handling  mechanism  is  thus  flexible  in  that  the 
actual  response  to  the  exception  depends  on  the  context  in 
which  it  occurs. 

The  specific  details  of  this  exception  handling  mechanism 
in  PSN  are  taken  from  TAXIS  [Wong  1980  ].  Modifications  were 
necessary  in  areas  where  the  two  formalisms  do  not  match 
exactly  and  to  adapt  the  mechanism  to  the  PSN  definitions  of 
inheritance.  In  PSN  an  exception  occurs  in  the  execution  of  a 
program  when  the  evaluation  of  the  "eval"  property  of  any  of 
the  prerequisite,  body,  or  returns  slots  fails  or  if  the  value 
returned  to  a  prerequisite  slot  is  false.  Associated  with  each 
of  these  slots  is  an  "exception"  property  value  which  is  a  form 
which  creates  an  instance  of  the  metaclass  "EXCEPTION_CLASSHS". 
When  the  evaluation  fails,  the  process  of  raising  the  exception 
involves  executing  this  form  to  create  an  instance  of  the 
exception  class.  The  TAXIS  mechanism  allows  exceptions  to  be 
raised  only  when  the  value  returned  to  a  prerequisite  is  false. 
PSN  however  allows  a  statement  called  "fail"  to  be  executed, 
causing  a  form  to  fail.  Also,  an  exception  will  be  raised  for 
a  slot  if  it  is  incapable  of  handling  an  exception  raised  in 
its  evaluation. 

As  described  above,  the  action  to  be  performed  to  handle 
the  exception  is  specified  in  the  calling  program.  More 

specifically ,  any  evaluatable  slot  has  a  value  for  the 

"exception-action*5  slot  which  is  of  type 

"EXCEPTION-HANDLER-LINK".  An  instance  of  this  metaclass  has 
slots  whose  types  are  exception  classes  (instances  of 

"EXCEPTION_CLASSES")  and  have  In  addition  associated  programs 
via  the  "handler"  property.  Figure  3-12  shows  an  example  of 
the  various  items  associated  with  exceptions.  When  an 
exception  is  raised,  the  interpreter  finds  the  calling  process 
by  following  the  dynamic  arc;  it  can  then  determine  the  active 
slot  and  create  an  instance  of  the  corresponding 

"exception-action"  value.  It  then  searches  for  a  slot  in  the 
exception  handler  link  which  has  as  type  a  class  which  is  a 
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type  of  the  exception  which  was  raised.  The  program  which  is 
the  "handler”  for  this  slot  is  then  executed  with  the  exception 
as  a  parameter,  and  the  returned  value  is  used  for  the  value  of 
the  slot  whose  form  originally  failed. 

This  mechanism  differs  in  one  important  way  from  that  of 
TAXIS.  In  TAXIS,  control  is  returned  to  the  next  expression  in 
the  program  in  which  the  exception  was  raised,  while  PSN 
replaces  this  program  with  the  exception  handler.  It  is 
difficult  to  see  how  the  zero  divide  problem  would  be  fixed 
using  the  TAXIS  mechanisms. 

As  an  example,  consider  again  the  objects  in  figure  3-12. 
If  the  division  in  "PROGRAM-2"  should  fail  perhaps  in  an 
attempt  to  divide  by  zero,  an  instance  of  the  exception 
"CANNOT- DIVIDE"  is  raised.  The  dynamic  link  is  then  followed 
back  to  the  instance  of  "PROGRAM-1"  where  "EHL 1"  is  the 
exception  handler  link  for  the  active  slot.  In  this  class,  the 
slot  "b"  has  type  "C ANNOT-DI VIDE" ,  thus  the  associated  handler, 
"PROGRAM-4"  is  executed,  and  the  value  returned  is  bound  to  the 
slot  "a2"  in  "PROGRAM-2"  and  execution  continues. 

Since  exceptions  and  exception  handler  links  are  classes, 
the  IS- A  constraint  on  "exception",  "exception-action",  and 
"handler"  links  is  simply  the  requirement  that  the  values 
remain  unchanged  or  that  the  values  for  the  specialized  slots 
are  IS-A  those  of  the  originals.  This  gives  the  exception 
mechanism  the  full  flexibility  provided  to  programs  by  the 
inheritance  mechanism.  Thus  when  a  program  is  specialized,  the 
exceptions  associated  with  various  slots  might  be  specialized, 
the  handlers  for  various  exceptions  may  be  specialized,  and 
more  kinds  of  exceptions  may  be  provided  with  handlers.  Figure 
3-13  illustrates  specialization  of  handler  links,  and  figure 
3-14  shows  the  specialization  of  exception  classes. 

There  are  of  course  default  actions  which  occur  when  no 
exception  class  or  exception  handler  links  are  specified.  The 
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default  exception  for  slots  is  the  class  19 GENE RAL_EXCEPTION ". 
All  exception  classes  must  be  subclasses  of  this  class  so  that 
the  default  handler  link  can  deal  with  the  exception.  The 
default  handler  link  joins  the  "GENERAL_EXCEPTXON"  to  the 
program  "abort";  therefore  if  any  exception  is  raised  and  no 
handler  is  specified,  the  program  will  be  aborted.  Handler 
links  need  not  be  subclasses  of  this  general  link,  and  it  is 
thus  possible  that  no  handler  is  supplied  for  an  exception.  In 
such  cases  the  interpreter  will  abort  the  operation. 


Exception  handlers  always  receive  the  exception  they  are 
to  deal  with  as  a  parameter  value  for  the  slot  "exception". 
This  reguires  that  all  programs  which  are  used  to  handle 
exceptions  be  subclasses  of  the  program  "GENERAL_HANDLER"  which 
simply  supplies  the  definition  for  this  parameter. 


CHAPTER  IV 


Implementation  -  Overview  and  Primitives 


I V .  1 .  Overview 


The  previous  two  chapters  have  described  PSN  as  a  semantic 
network  consisting  of  objects  and  relations  between  them. 
Diagrams  were  used  to  illustrate  parts  of  such  a  network.  The 
formalism  also  involves  the  ability  to  affect  changes  in  this 
static  representation;  the  forms  and  programs  introduced  in 
chapter  three  are  structures  in  the  network  which  can  be 
interpreted  to  cause  transformations.  The  emphasis  in  an 
implementation  is  on  the  introduction  of  such  forms  and 
programs  into  the  knowledge  base  and  on  their  subsequent 
execution. 


The  representation  of  the  network  cannot ,  however,  be 
ignored.  For  programs  to  be  useful  there  must  be  objects  and 
relationships  on  which  they  can  operate.  One  of  the  concerns 
of  this  chapter  is  the  description  of  a  storage  representation 
of  a  semantic  network  for  the  PSN  system.  This  representation 
is  a  distinct  level  of  the  implementation  in  that  the  interface 
with  the  remaining  system  is  through  a  small  number  of 
operations  which  may  easily  be  redefined  should,  a  different 
representation  be  desired. 

The  opposite  pole  of  the  implementation  is  the  translation 
of  the  PSN  language  into  objects,  especially  forms,  in  the 
knowledge  base.  For  example,  if  the  user  types 

’’make  John  instanceof  PERSON", 

the  translator  creates  a  form  which  is  basically  a  call  to  the 
to-add  program  of  "PERSON"  with  "John"  as  the  value  of  the 
parameter  representing  the  object  which  should  be  made  an 
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instance  of  the  class.  A  form  more  commonly  found  in  other 
computer  systems  might  be  an  arithmetic  operation  such  as 

"4  +  5.. 

which  would  cause  a  call  to  the  program.  More  aspects  of 

this  language  will  be  discussed  in  chapter  five,  and  a  complete 
syntax  is  provided  in  the  appendix. 


Once  the  form  entered  by  a  user  is  compiled,  the  new 
object  in  the  knowledge  base  is  interpreted.  The  interpreter 
routine  is  a  major  component  of  the  system  and  is  also 
described  in  chapter  five.  The  result  of  the  interpretation 
will  be  a  PSN  object  (possibly  "unknown") .  The  external  name 
of  this  object  will  be  printed  for  the  user;  in  the  case  of  the 
addition,  for  example,  "9M  would  be  printed  at  the  terminal. 


The  creation  of  objects  will  be  a  very  frequent  occurrence 
in  the  use  of  PSN.  In  particular,  each  command  which  is 
entered  results  in  the  creation  of  at  least  one  class. 
Therefore  the  system  offers  as  primitive  routines  for  creating 
objects,  applying  the  add  programs  of  classes,  adding  IS-A 
relationships,  and  adding  and  inheriting  structure.  A  routine 
is  primitive  if  it  appears  as  a  black  box  to  PSN  (ie. ,  its 
actions  are  not  reflected  in  its  internal  structure). 
Primitive  routines  are  generally  the  values  of  ,fevalH 
properties  of  "returns"  slots  of  system  supplied  PSN  programs. 
This  chapter  looks  at  the  algorithms  used  in  some  primitive 
routines  while  chapter  five  will  discuss  the  system  supplied 
programs.  It  is  possible  to  provide  a  PSN  system  where  the 
only  primitive  routines  are  those  which  interface  with  the 
stored  knowledge  base,  but  routines  encoded  in  LISP  execute  far 
more  efficiently  than  PSN  programs. 


The  final  aspect  of  the  system  is  a  set  of  programs  which 
are  the  default  programs  for  user  created  classes  and 
relations.  The  standard  routines  are  also  coded  as  primitive 
routines.  These  routines  are  what  will  generally  be  used  (with 
possible  additional  actions)  to  provide  the  semantics  of  stored 
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classes  and  relations,  that  is,  those  classes  and  relations 
which  acknowledge  instances  by  a  specific  change  to  the 
knowledge  base.  For  a  given  class  it  is  not  required  that  the 
user  use  standard  routines;  for  example,  he  could  create  a 
relation  called  " ray_instance_of "  and  add  objects  to  classes  by 
asserting  this  relation.  The  relation  would  however  also  need 
four  programs,  and  if  these  are  not  to  be  the  standard 
programs,  additional  classes  or  relations  are  required  to  store 
the  assertion.  It  is  clear,  therefore,  that  at  some  time  a 
primitive  function  will  be  needed  to  store  an  assertion  or  an 
instance.  A  discussion  of  the  standard  routines  forms  the 
concluding  sections  of  this  chapter. 

IV. 2.  Storage  Representation  of  PSN  Objects 

The  representation  of  the  semantic  network  has  two  levels: 
the  first  is  the  actual  physical  storage  which  for  this  system 
uses  LIS?  structures  (but  could  perhaps  use  records  on  a  disk, 
etc.),  and  the  second  is  the  use  of  this  storage  in 
representing  objects,  slots,  assertions,  IS-A,  etc.  The 
interface  to  the  storage  level  is  very  simple:  the  standard 
parameters  involve  the  name  of  a  PSN  object  and  a  storage  field 
name  (property) .  In  retrieving  from  storage  these  parameters 
are  sufficient  to  specify  a  value  which  is  usually  the  name  of 
a  PSN  object.  When  a  value  is  to  be  stored  the  value  must 
additionally  be  specified.  Certain  classes  of  objects  are, 
however,  not  represented  in  the  standard  fashion.  Such  objects 
are  strings,  numbers,  and  Intervals  and  are  characterized  by 
the  fact  that  they  behave  as  if  all  such  objects  permanently 
exist  (they  cannot  be  created  nor  destroyed)  and  that  they  may 
have  no  internal  structure. 

Subsection  two  and  following  describe  the  higher  levels 
involved  in  representing  a  semantic  network.  The  problems 
solved  there  are  representing  classes  and  slots,  storing  IS-A 
between  classes,  representing  assertions,  and  associating 
property  values  with  objects.  Of  particular  importance  is  the 
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association  of  slots  with  classes.  In  PSN,  although  an 
inherited  slot  may  have  different  properties  than  it  has  in  a 
superclass,  a  slot  is  a  unique  object  irrespective  of  the 
number  of  classes  in  which  it  appears.  It  was  necessary, 
therefore  to  devise  a  mechanism  by  which  the  appropriate  view 
of  a  slot  is  associated  with  a  class.  In  this  representation 
inheritance  of  structure  is  completed  at  the  time  of  creation 
of  the  slot;  that  is,  it  is  not  necessary  to  search  via  IS-A 
for  the  appropriate  view  of  a  slot.  This  mechanism  does, 
however  restrict  the  definition  of  structure  and  the  assertion 
of  IS-A  to  the  time  of  creation  of  a  class. 

IV. 2.  1  Standard  Objects 

\ 

Most  PSN  objects  are  stored  as  unique  LISP  atoms;  the 
names  of  these  atoms  are  the  internal  names  of  objects  and  play 
the  same  role  with  respect  to  the  implemented  net  as  do 
external  names  to  the  formal  net.  The  property  lists  of  these 
atoms  are  used  to  store  the  relationships  that  the  atom  has  in 
a  semantic  network.  All  atoms  have  a  ‘'SYSTEM;"  property  which 
stores  the  external  name  of  the  object,  and  an  "I NST ANCEOF : " 
property  which  stores  a  list  of  the  types  of  the  object. 

Although  most  of  the  system  defined  properties  of  an 
object  are  stored  as  values  on  the  LISP  property  lists,  the 
higher  levels  of  the  system  do  not  depend  on  this 
representation.  All  access  to  properties  of  objects  are  made 
through  a  set  of  functions  which  decide  how  to  store  or  fetch  a 
value  given  an  object  and  a  property,  hence  in  later  extensions 
of  the  system  it  will  be  possible  to  change  the  representation 
of  certain  classes  of  objects  or  properties  without 
modification  of  the  majority  of  the  system. 

The  terms  property  and  property  value  now  have  three 
different  meanings  in  various  contexts.  When  discussing 
properties  in  the  formal  view  of  PSN,  a  property  of  an  object 
corresponds  to  a  property  definition  or  slot  in  one  of  its 


64 


IV. 2  Object  Storage 


types,  and  a  property  value  is  a  slot  value,  a  value  associated 
to  the  object  by  that  property.  In  the  general  discussion  of 
the  implementation  a  property  is  a  LISP  atom  which  is  used  with 
atoms  representing  PSN  objects  to  access  s-expressions  stored 
with  the  objects  via  the  basic  functions.  In  this  context  the 
property  "INSTANCE-OF: ”  is  an  atom  which  when  passed  to  the 
basic  retrieval  function  with  some  object  will  reference  the 
list  of  classes  of  which  the  object  is  an  instance.  Finally, 
the  third  view  is  the  standard  LISP  view  in  which  a  property  is 
an  atomic  flag  which  when  occurring  in  a  property  list  of  an 
atom  indicates  a  value.  In  the  remaining  discussion,  the  last 
of  these  meanings  will  not  be  intended  unless  it  is 
specifically  stated.  Which  of  the  other  two  meanings  is 
intended  will  be  obvious  from  the  context  of  its  use. 

Certain  classes  of  objects  behave  as  if  every  instance 
permanently  exists  in  the  knowledge  base;  that  is,  any  such 
object  can  be  referenced  from  the  input  language  and  be  used 
without  previously  being  created,  unreferenced  objects  from 
these  classes  are  not  explicitly  stored,  and  references  to 
these  objects  are  not  uniquely  stored.  Such  objects  are 
instances  of  classes  which  P.  Schneider  [Schneider  19V3a]  has 
called  intensional,  and  examples  are  numbers  and  strings.  In 
general,  these  objects  have  certain  restrictions  on  their  use; 
they  have  no  internal  structure  and  no  properties  may  be 
assigned  to  them;  they  may  not  appear  as  domain  instances  of 
assertions;  the  range  interval  of  assertions  in  which  they 
appear  is  not  checked;  they  may  not  be  created  or  destroyed; 
and,  relations  which  have  such  classes  as  ranges  are  not 
invertable  by  the  standard  routines.  Other  such  objects  are 
t£pe  sets  consisting  of  a  list  of  classes,  intervals,  and 
slot-specs ,  a  special  type  of  object  used  by  the  system  for 
referencing  slots. 


These  last  three  types  of 
in  some  sense,  for  although 
objects  all  participate  in 
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hierarchies  are  predefined  and  permanent  - —  it  is  impossible 
for  the  user  to  modify  them.  For  type  sets,  "A81  IS-A  *'B"  if 
and  only  if  for  each  element  of  '*Bn  there  is  an  element  of  "A” 
which  is  the  same  as  or  an  IS-A  descendant  of  the  element  of 
"B".  This  is  equivalent  to  saying  that  if  an  object  "x11  is  an 
instance  of  every  class  in  “A"  then  it  is  an  instance  of  every 
class  in  ,,Bn,  hence  type  sets  are  used  as  the  values  of  the 
'•type'’  properties  of  slots  or  the  set  of  classes  of  which  an 
object  is  an  instance.  Type  sets  are  stored  as  non-redundant 
txpe  sets  in  which  none  of  the  classes  of  the  set  is  an  IS-A 
descendant  of  or  is  equal  to  any  other  member  of  the  set. 

The  predefined  IS-A  for  intervals  is  simply  containment: 
if  "<i,  j>"  IS-A  "<k,l>(8  then  i  is  greater  than  or  equal  to  k 
and  j  is  less  than  or  equal  to  1.  Of  course,  all  valid 
intervals  must  have  the  lower  bound  less  than  or  equal  to  the 
upper  bound. 

A  slot  specification  is  an  object  which  indicates  a 
reference  to  a  slot.  Later,  it  will  be  seen  that  redefinitions 
of  a  slot,  although  formally  the  same  object,  are  stored  as 
distinct  internal  objects.  A  slot  specification  consists  of  a 
class  object  and  an  external  slot  name  and  is  used  by  the 
interpreter  to  resolve  variable  bindings.  This  operation 
involves  finding  a  process  which  contains  among  its  types  a 
class  which  has  as  a  part  the  given  slot.  Given  a  slot 
specification,  the  search  becomes  a  search  for  a  process  which 
contains  among  its  types  the  class  of  a  slot  specification  or 
an  IS-A  descendant  of  this  class.  When  this  class  is  found, 
the  internal  representation  of  the  appropriate  version  of  the 
slot  may  be  found.  One  slot  specification  is  a  specialization 
of  another  if  the  class  of  the  first  is  an  IS-A  descendant  of 
the  class  of  the  first,  and  the  slot  names  are  identical. 
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IV. 2. 2  Storing  Classes 

Current  discussions  in  PSN  rely  heavily  on  the  concepts  of 
classes  and  the  IS-A  hierarchy.  Therefore,  this  implementation 
provides  mechanisms  which  implement  the  special  features  of 
classes  as  primitive  operations.  In  particular,  an  atom 
representing  a  class  may  have  any  of  five  special  system 

properties:  "INSTANCES:",  "ISA:",  "Isl-CHILDREN: ” , 

"STRUCTURE: " ,  and  "META-STRUCTURE: " .  Classes  which  use  the 
standard  to-add  program  will  keep  track  of  their  instances  by 
maintaining  a  list  of  instances  as  the  value  of  the 

"INSTANCES:"  property.  "ISA:”  and  "ISA-CHILDREN:"  implement 
the  IS-A  hierarchy,  the  value  of  the  "ISA:"  property  being  a 
non-redundant  set  of  classes  of  which  a  class  is  an  IS-A 

descendant,  and  the  "ISA-CHILDREN:"  property  being  a  list  of 
all  classes  which  include  the  class  as  an  element  of  their 
"ISA:"  properties.  "STRUCTURE:"  and  "META-STRUCTURE:" 
implement  the  PART-OF  relation  where  each  stores  a  list  of 

associations  of  external  names  to  internal  objects,  the 
instances  of  "slot"  being  stored  as  structure,  and  instances  of 
metaslot  being  stored  as  metastructure. 

Every  class  stores  this  complete  list  of  internal  objects 

( 

so  that  the  slot  accessing  mechanism  need  not  concern  itself 
with  IS-A.  However,  objects  which  are  not  metaslots  and  are 
inherited  without  modification  are  stored  uniquely;  if  "A"  IS-A 
"B"  and  "a"  is  a  slot  inherited  from  "B"  with  no  changes,  then 
references  to  "a"  in  the  context  of  either  "A"  or  "B"  will 
produce  the  same  internal  object.  On  the  other  hand, 
modification  in  inheritance  will  result  in  a  new  internal 
object.  This  is  one  means  of  implementing  a  limited  context 
mechanism:  externally  a  slot  is  to  be  viewed  as  a  unique  object 
whose  properties  are  to  be  accessed  in  the  context  of  the  class 
being  referenced.  The  various  Internal  representations  of  a 
slot  or  metaslot  are  bound  together  in  a  redefinition  hierarchy 
implemented  by  the  system  properties  "REDEFINES:"  and 
"EEDEFINED-BY: "  whose  values  are  related  in  a  fashion  similar 
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to  that  of  IS-A.  In  particular  a  non-r edundant  set  of  internal 
representations  of  a  slot  (or  metaslot)  is  a  set  in  which  no 
object  is  a  redefinition  of  another. 

The  "SYSTEM:”  property  of  a  slot  is  a  LISP  dotted  pair  of 
which  the  CAR  is  the  metaslot  of  which  the  top  of  the 
redefinition  hierarchy  is  an  instance  (at  present  a  slot  may  be 
an  instance  of  only  one  metaslot)  ,  and  the  C DR  is  the  external 
name  of  the  slot. 

The  PAPT-OF  relation,  when  implemented  this  way,  is  not 
easily  invertable,  that  is,  stored  links  reference  slot 
representations  from  classes,  but  no  stored  links  reference 
defining  classes  from  the  slots. 

IV. 2. 3  Storing  and  Accessing  Property  Values 

The  association  between  objects  and  their  property  values 
are  stored  as  properties  on  the  LIS?  property  list  of  the 
object  where  the  name  used  is  the  atom  which  is  the  internal 
representation  of  the  slot  which  defines  the  particular 
relationship.  Thus  the  operations  of  storing  and  retrieving 
slot  values  must  involve  the  class  of  which  the  object  is  an 
instance  so  that  the  appropriate  internal  object  may  be  found. 
The  operation  " IDENTIFY-SLOT”  takes  as  parameters  as  list  of 
classes  and  an  external  slot  name  and  searches  the  structures 
of  the  classes  for  slots  having  that  name.  Should  more  than 
one  internal  object  be  returned,  the  non-red undant  set  of 
objects  is  computed.  If  this  set  contains  a  single  object,  the 
identification  succeeds,  otherwise  if  fails. 

When  a  slot  value  reference  is  made  with  respect  to  some 
object,  the  set  of  classes  passed  to  the  identification 
operation  is  the  non-redundant  set  of  types  of  the  object.  The 
object  which  is  then  returned  can  be  used  for  storing  or 
retrieving  values.  The  storage  operation  will  check  that  the 
proposed  value  satisfies  the  types  and  restrictions  of  the 
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slot,  hence  the  identification  of  the  internal  object  was 
necessary  even  had  some  other  storage  mechanism  been 
implemented. 


Value  retrieval  also  requires  the  identity  of  the  internal 
representation  to  access  properties  of  the  slot;  specifically, 
the  value  of  the  default  property  is 
operation  sequence  first  attempts  to  fetch 
stored  and  the  object  is  a  class,  a: 
inherited  value  is  made.  In  Inheritance, 
find  the  set  of  all  values  for  the  app: 

IS-A  parents  of  the  class  which  have  the  p 
has  more  than  one  member  all  of  which  are  i 
the  non- redundant  set  of  classes.  In  any  case,  if 
value  is  found,  then  this  is  the  inherited  value,  otherwise, 
nothing  is  inherited  and  the  default  value,  if  any,  is  used. 
When  there  is  no  default  value  at  this  point,  the  special 
object  "unknown”  is  returned  as  the  value  of  the  retrieval. 
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IV. 2. 4  Storing  Relation  Instances 


The  standard  program  for  storing  assertions  of  PSN 
relations  stores  the  assertion  by  adding  properties  to  both  the 
domain  and  range  objects.  These  properties  are  complex  in  that 
the  retrieval  routine  requires  more  than  just  a  property  and  an 
object.  The  first  such  property  is  the  "D-R-LIST;"  which  is 
associated  with  a  domain  Instance  of  an  assertion.  The 
retrieval  operation  requires  the  property,  the  domain  instance, 
and  the  relation  object  and  returns  an  s-expression  of  the  form 

"  [CrelationXcountXinst  1><inst2>  . .  . )  " 
where  count  is  the  number  of  elements  following  and  the 
"<insti>"  are  objects  which  are  the  range  instances  of  the 
assertions  of  the  relation  in  which  the  domain  instance  is 
involved.  The  property  "R-D-LIST:"  is  the  opposite;  it 
references  the  list  of  domain  instances  for  a  range  instance. 
A  particular  assertion  is  then  represented  by  a  pointer  to  the 
range  instance  in  the  "D-E-LIST:"  property  of  the  domain 
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instance  and  a  pointer  to  the  domain  instance  from  the  range 
instance  in  the  "R-D-LIST:"  property  of  the  range  instance. 
The  latter  will  be  missing  in  the  case  of  relations  which  are 
not  invertable  because  their  domains  are  intensional  classes. 

The  retrieval  routines  are  also  capable  of  retrieving  the 
number  of  assertions  an  object  is  involved  in  as  a  domain 
instance  given  the  "DOM AIN-INTERV AL-COUNT :  "  property,  the 
object,  and  the  relation.  The  "R  ANGE-INT3RV  AL-COONT : 11  property 
similarity  results  in  the  number  of  assertions  the  object 
participates  in  as  a  range  instance. 

I V . 3 .  Creating  objects 

As  mentioned  in  the  introduction  to  this  chapter,  the 
algorithms  for  creating  objects  are  encoded  as  primitive 
operations.  The  routine  which  is  most  often  used  for  this 
purpose  includes  a  number  of  other  primitive  operations. 
Firstly,  whenever  an  object  is  created,  it  must  become  an 
instance  of  some  class.  All  objects  are  at  least  instances  of 
the  class  "OBJECT".  Thus  when  an  object  is  created,  the  to-add 
program  of  at  least  one  class  is  applied  to  it.  The  second 
restriction  on  the  creation  of  objects  is  the  fact  that  a  class 
must  be  given  its  structure  and  IS-A  parents  at  this  time.  The 
routine  will  then  invoke  the  algorithms  for  adding  and 
inheriting  structure. 

IV. 3.  1  Objects 

The  routine  for  creating  objects  takes  a  number  of 
parameters,  of  which  all  but  the  list  of  types  are  optional. 
The  other  parameters  that  concern  the  user  are  a  list  of  IS-A 
parents  (for  classes) ,  a  data  structure  which  describes  the 
structure  of  a  class,  and  a  list  associating  properties  to  slot 
values.  Most  of  the  operations  shown  here  can  be  invoked 
separately  although  almost  invariably  the  user  will  cause  them 
to  be  run  as  calls  from  "NEW-FORM-BODY",  a  primitive  routine 
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which  is  the  body  of  the  predefined  program  "NEW". 

The  first  action  is  to  create  a  LISP  atom  as  the  storage 
location  of  the  new  object.  Usually  this  involves  using  GENSYM 
to  create  a  new  atom.  Often,  however,  for  internal  reasons, 
the  system  will  have  created  this  atom  earlier  and  pass  this 
atom  as  a  parameter  to  "NEW-FORM-BODY".  The  user  may  never 
himself  supply  a  name  for  this  slot  because  he  has  no  mechanism 
for  generating  a  new  location  and  will  therefore  make  the 
system  inconsistent.  The  actual  creation  is  done  by  a  basic 
function  called  "CRE ATE-OBJECT" ,  hence  apart  from  the  internal 
name,  the  system  need  know  nothing  about  the  representation  of 
objects. 

With  this  newly  created  object,  the  routine  now  associates 
the  types  to  the  object  by  the  "INSTANCEOF: "  property,  storing 
as  mentioned  before,  only  the  non-redundant  type  set.  This 
does  not  make  the  object  an  instance  of  its  types;  this 
property  is  necessary  only  for  the  slot  value  attachment 
mechanism.  However,  the  system  does  make  use  of  the  types  to 
determine  whether  the  new  object  is  a  class. 

If  the  object  is  to  be  a  class,  it  is  necessary  to  assert 
the  '’ISA:”  property  and  link  the  class  to  its  IS-A  parents  as 
described  in  the  subsection  on  the  storage  of  classes.  All 
classes  are  in  addition  made  IS-A  descendants  of  ’’OBJECT"  and 
all  programs  are  made  IS-A  descendants  of  "NULL_?ROGRA!vI"  and 
forms  of  "NULL_FORH". 

The  second  stage  for  classes  is  to  add  the  structure, 
using  that  inherited  from  IS-A  parents  and  that  supplied  as  a 
parameter  value.  The  details  of  this  are  described  in  the  next 
subsection.  The  special  actions  performed  for  classes  can  be 
considered  actions  which  should  be  performed  by  the  "to-add" 
program  of  "CLASS"  which  are  taken  inside  the  interpreter 
because  of  their  common  application  to  every  instance  of 
"CLASS". 
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The  final  step  is  to  run  the  '’to-add"  program  for  each  of 
the  types  of  the  object  so  that  the  object  actually  becomes  an 
instance  of  these  classes.  Here  it  is  important  that  only  the 
add  programs  of  classes  in  a  non- redundant  type  set  are  used, 
for  were  the  add  programs  of  both  a  class  and  some  subclass  of 
that  class  to  be  run,  the  common  actions  would  be  duplicated 
resulting  in  possible  inconsistencies  in  the  knowledge  base. 

IV. 3. 2  Adding  Structure 

The  routine  for  adding  structures  has  as  parameters  a  list 
structure  defining  the  new  features  of  a  structure,  an 
inherited  structure,  and  a  metastructure.  The  inherited 
structure  will  in  general  arise  from  more  than  one  IS-A  parent, 
and  the  metastructure  will  arise  from  more  than  one  type.  The 
mapping  from  many  structures  to  one  structure  is  done  by  a 
merging  operation  which  is  applied  to  the  total  structure  to 
produce  the  inherited  structure,  and  to  only  metastructures  to 
produce  the  metastructure. 

The  merging  operation  consists  simply  of  checking  that 
there  exists  a  unique  redefinition  among  the  set  of  inherited 
views  of  each  slot.  Since  slots  are  referenced  by  their 
external  names  by  the  system,  two  unrelated  slots  with  the  same 
name  will  result  in  a  set  of  slots  for  which  there  is  no  unique 
redefinition.  Therefore,  in  this  implementation,  it  is  not 
legal  to  inherit  different  slots  with  non-unique  names.  It  is 
also  not  legal  to  inherit  a  set  of  different  redefinitions  of  a 
slot  for  which  there  is  no  unique  redefinition. 

For  each  inherited  slot,  the  routine  checks  for 
modifications  desired  in  the  properties  of  the  slot.  If  such 
do  not  exist  and  the  slot  is  not  a  metaslot,  no  action  is 
taken.  Otherwise,  the  operation  of  redefining  the  slot 
proceeds;  the  term  old  slot  refers  to  the  inherited  slot  and 
new  slot  to  the  redefinition  which  is  being  created.  There  are 
two  prerequisites  to  the  redefinition  operation: 
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1.  among  the  types  of  the  new  slot  (the  non-redundant 
sub-type  set  of  the  union  of  the  types  of  the  old  slot 
and  the  newly  specified  types)  there  must  be  a  class 
which  is  a  member  of  the  merged  metastructure; 

2.  there  may  be  only  one  metaslot  in  the  non-red undant  type 
set  of  the  new  slot. 

If  these  prereguistes  are  satisfied  the  operations  are; 

1.  An  object  is  created  using  the  routine  of  the  previous 
section,  exactly  as  a  normal  object  with  the  exception 
that  no  property  values  are  passed  to  the  add  routine 
(the  slot  redefinition  routine  will  assign  them  in  the 
next  step) .  A  result  of  this  is  that  the  fetch  program 
for  '•slot'1  will  fetch  as  distinct  objects  the  various 
redefinitions  of  a  slot. 

2.  The  property  values  of  the  new  slot  are  assigned:  for 
most  properties,  the  new  value  is  compared  with  the  old 
value  (if  any)  to  check  that  the  IS-A  constraint  is 
satisfied;  in  the  case  of  the  "type"  and  "restriction" 
properties,  a  new  value  is  computed  from  the  old  value 
and  the  value  supplied  as  a  parameter.  The  "type" 
property  of  the  new  slot  is  computed  as  the 
n on-redundant  type  set  contained  in  the  union  of  the 
value  for  the  old  slot  and  the  newly  supplied  types, 
hence  the  IS-A  constraint  is  automatically  satisfied. 
Similarity,  the  restriction  for  the  new  slot  is  a  form 
which  is  the  logical  "and"  of  the  old  restriction  and 
any  newly  supplied  restriction. 

3.  The  "REDEFINES:",  "REDEFINSD-BY: " ,  and  "SYSTEM:" 
properties  are  asserted  for  the  appropriate  objects. 


When  these  operations  have  been  carried  out  for  all 
inherited  slots,  there  may  remain  unused  parts  of  the  structure 
definition  parameter.  These  are  taken  as  definitions  of  new 
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slots  whose  creation  simply  involves  a  call  to  the  object 
creation  routine  followed  by  the  assertion  of  the  appropriate 
"SYSTEM:"  property.  In  this  case,  the  property  values  are 
passed,  therefore  the  creation  of  new  slots  is  exactly  the 
creation  of  new  objects. 

IV. 4.  The  Standard  Soutines  -  Adding 

IV. 4. 1  Objects 

The  standard  routine  for  adding  objects  to  a  class  simply 
causes  the  object  to  be  stored  in  the  list  of  objects  which  is 
the  value  of  the  "INSTANCES:"  property  of  the  class.  The 
routine  will  not  accept  instances  of  intensional  classes  such 
as  "NUMBER". 

IV. 4. 2  Assertions 

The  standard  routine  for  adding  assertions  of  a  relation 
between  two  objects  has  a  number  of  preregui sites : 

1.  The  source  of  the  proposed  assertion  must  be  an  instance 
of  the  domain  of  the  relation,  and,  similarity,  the 
target  of  the  assertion  must  be  an  instance  of  the 
range. 

2.  An  assertion  of  the  same  relation  must  not  already  hold 
between  the  two  objects.  In  addition,  there  must  be  no 
assertion  with  this  source  and  target  of  any  relation 
which  is  an  IS-A  ancestor  of  the  relation,  because  the 
new  assertion  would  result  in  two  instances  of  this 
ancestor . 

3.  The  proposed  assertion  must  not  violate  the  "d-int" 
(domain  interval)  of  the  relation  or  any  IS-A  ancestor 
for  the  source  object.  Similarity,  the  target  may  not 
participate  as  the  target  in  more  assertions  than  are 
allowed  by  the  "r-int”  property  of  the  relation  and  its 
ancestors. 
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The  algorithm  for  the  last  two  conditions  involve  a  search 
of  the  IS- A  hierarchy.  For  condition  two,  the  test  program  of 
the  relation  and  each  ancestor  must  be  tried  on  the  source  and 
target.  For  condition  three,  for  each  of  the  same  relations,  a 
fetch  must  be  performed  for  all  assertions  in  which  the  source 
object  is  the  source.  These  objects  must  then  be  counted  and 
the  "r-int"  checked.  The  algorithm  avoids  much  work  by  only 
performing  the  fetch  if  the  upper  bound  is  finite.  The  lower 
bound  need  not  be  checked  because  the  fetch  programs  should 
return  at  least  the  minimum  number  of  objects,  filling  in 
"unknown"  to  meet  this  number.  Also,  the  program  assumes  that 
all  relations  in  the  IS-A  hierarchy  in  which  the  current 
relation  resides  will  use  the  same  assert  program.  This  allows 
the  fetching  operations  to  be  written  into  this  program  in  such 
a  way  so  that  the  instances  for  each  relation  are  fetched  only 
once,  even  if  the  IS-A  hierarchy  is  not  a  tree. 

Once  the  prerequisites  are  satisfied,  the  assertion  is 
stored  as  described  in  section  IV. 2. 4. 

IV.  5.  Standard  F.outines  -  Recognizers 

I V . 5 . 1  Objects 

The  standard  test  routine  must  return  "true"  if  the 
instance  which  it  is  recognizing  occurs  in  the  oiven  class  or 
any  descendant  of  this  class.  Because  the  standard  INSTANCE-OF 
assertion  is  stored  with  only  the  particular  class  of  which  the 
object  is  a  direct  instance,  it  will  often  be  necessary  that 
this  program  search  down  the  IS-A  hierarchy  to  verify 
membershit).  The  program  simply  calls  a  recursive  program  which 
returns  "false"  if  the  class  (its  parameter)  has  been  marked, 
returns  "true"  if  the  object  is  stored  directly  under  the 
present  class,  and  otherwise  marks  the  class  as  checked  and 
calls  itself  with  each  of  the  subclasses  of  the  present  class. 
The  marking  is  necessary,  of  course,  because  the  IS-A  hierarchy 
need  not  be  a  tree,  hence  a  class  may  be  reached  in  more  than 
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one  way  as  a  descendant  of  some  other  class. 

TV. 5. 2  Assertions 

This  operation  is  very  similar  to  that  for  non-assertion 
objects  because  each  assertion  is  found  through  the  relation  of 
which  it  is  a  direct  instance.  Again  a  search  of  the  IS-A 
hierarchy  in  which  each  relation  is  marked  as  it  is  checked  is 
necessary.  The  existence  of  the  assertion  must  be  checked  only 
in  one  direction. 

IV. 6.  Standard  Routines  -  Killing  and  Fetching 

The  operation  of  killing  is  simply  the  inverse  of  the 
addition  operation.  Fetching  corresponds  to  testing  because  it 
also  involves  searching  the  IS-A  hierarchy  to  find  all 
instances.  These  algorithms  do  not  require  further  discussion. 


CHAPTER  V 

Implementation - parsing;  and  Interpreting 


V. 1.  Introduction 


A  major  shortcoming  of  previous  implementations  of  PSN  has 
been  the  lack  of  an  input  language  designed  to  express  the 
concepts  of  the  formalism.  These  implementations  were  simply 
extensions  to  LIS?  in  which  the  standard  programs  for  classes 
and  relations  and  special  programs  for  such  objects  as  "CLAS S" 
and  "RELATION"  were  supplied.  In  general,  the  list  structures 
reguired  as  parameters  were  complicated  and  tedious  to  use. 
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s  problem  is  magnified  when  one  tries  to  create  program 
as  described  in  chapter  three.  Programs  usually 
that  a  number  of  form  objects  be  created,  a  task  which 
systems  would  reguire  a  number  of  calls  to  the 
routines  in  which  the  most  nested  forms  (for  example, 
statement  of  a  begin  block)  must  be  created  first, 
sible  solutions  are  to  either  write  LISP  functions  for 
specialized  creations  which  can  have  simplified  calling 
s,  or  to  provide  a  parser  for  a  new  input  language, 
two  of  this  chapter  describes  some  features  of  such  a 
and  some  aspects  of  the  translator  for  this  language. 


Section  three  describes  an  interpreter  which  can  execute 
the  objects  which  describe  programs.  This  includes  a 
discussion  of  how  primitive  operations  are  recognized,  and  the 
implementation  of  the  relation  "dynamic".  The  final  section 
describes  the  implementation  of  several  predefined  programs  and 
their  resulting  forms;  these  are  the  forms  generated  by  the 
parser  to  implement  the  various  operations  such  as  creating 
objects,  begin  blocks,  for  loops,  etc. 
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V. 2.  Parsing 


V.  2.  1  The  language 

The  PSN  language  used  in  this  implementation  is  based  on 
the  language  introduced  in  [Levesque  1977],  Many  of  the 
features  and  shorthands  in  Levesque' s  language  have  not  been 
included.  The  design  goals  were 

1.  to  provide  the  basic  mechanisms  of  PSN,  that  is,  the 
capability  to  specify  procedural  attachment,  create 
objects  and  assertions,  and  assert  that  objects  have 
types ; 

2.  to  provide  basic  programming  language  constructs  with 
which  programs  specifying  the  semantics  of  PSN  objects 
could  be  written; 

3.  to  provide  a  language  that  can  be  parsed  deter ministicly 
with  one  or  two  token  look  ahead; 

4.  to  provide  some  the  declarative  aids,  such  as  IS-A, 
which  simplify  the  task  of  building  knowledge  bases. 
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the  use  of  the  slot  as  a  variable  is  indicated  by  using  the 
external  name  of  the  slot.  For  example 
’’factorial  :=  program 
parameters 

n  :  =  a  NUMBER  end  slot 
prerequisites 

pr 1  :=  a  BOOLEAN  vith 
eval  <-  [  n  >=  0  1 

•  •  • 

end  program” 

shows  the  slot  referred  to  by  "n”  being  used  as  a  variable.  It 
is  important  to  recall  that  once  such  a  variable  has  been 
assigned  a  value,  the  assignment  cannot  be  changed. 

The  other  important  aspects  of  the  language  involve  the 
invocation  of  the  four  programs  associated  with  classes  and 
relations.  For  example, 

” make  Helen  instanceof  STUDENT” 

invokes  the  add  program  of  the  class  "STUDENT”.  A  unique 
feature  is  the  jior  loop  which  takes  an  index  variable  through 
the  values  returned  by  a  generator  as  in 

"for  x  in  PERSON  do  print  x  end”. 

In  this  case  the  generator  is  the  to-fetch  program  of  the  class 
"PERSON".  Section  four  of  this  chapter  explains  how  this  can 
be  implemented  in  PSN. 

Most  of  the  language  constructs  begin  and  end  with  a 
reserved  keyword  so  that  parsing  is  very  simple.  For  example, 
the  examples  above  show  that  a  program  definition  begins  with 
"program"  and  ends  with  "end  program" .  Options  are  signalled 
by  a  keyword  beginning  the  option  before  the  keyword  ending  the 
construct.  Thus  in  creating  a  new  object  one  can  specify  IS-A 
parents,  structure,  and  slot  values  as  in 

"new  CLASS  isa  ...  structure  ...  with  ...  end  new". 
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V.  2.2  The  Scanner 
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sequence 
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i  ve: 

text  is 

read  the 

parser  works  until 

the 

exhausted.  This  arrangement  allows  the 
interactive  control  of  the  process  of  parsin 
explains  how  the  interactive  control  has  be 
scanner  used  for  the  system  is  basicly  an  i 
algorithm  discussed  in  [  Gries  1971]. 

When  the  parser  requires  a  new  token  it 
called  "ADVANCE"  which  pops  a  token  of 
tokens.  These  tokens  are  either  LIS? 
keywords  and  printable  operators,  or  pairs 

"  (<token  type>  .  <literal>) 
where  the  token  type  is  one  of  "NAME"*  "ST 
the  name  of  an  operator,  and  the  literal  is 
of  the  token.  "ADVANCE"  sets  the  token  t 
the  parser,  using  the  token  type  as  the  lite 
no  literal. 

When  the  list  of  input  tokens  is  e 
calls  a  routine  to  produce  a  new  list  of  tok 
buffer.  This  routine,  which  is  known  as  the 
an  entire  line  of  input  at  a  time.  Its  cont 
follows:  if  the  last  token  found  was  a  con 

the  required  action,  otherwise,  add  this  tok 
tokens  to  be  returned  and  invoke  the  scan 
with  the  current  character  in  the  input  buff 
result  to  the  last  token  found.  Initia 
found  is  set  so  that  the  program  runs  the  sc 
first  token  in  the  buffer. 

The  control  tokens  are: 

end  of  line:  This  results  when  a  carr 
feed,  an  or  escape  character  is  typed 


e  the  parser  with  a 
after  a  line  of 
tokens  supplied  are 
introduction  of 
g.  This  subsection 
en  included.  The 
implementation  of  an 

calls  a  routine 
f  the  list  of  input 
atoms  representing 

it 

RING",  " NUMBER" ,  or 
the  print  version 
ype  and  literal  for 
ral  when  there  is 

xhausted ,  "ADVANCE" 
ens  from  the  input 
scanner,  processes 
rol  loop  works  as 
trol  token,  perform 
en  to  the  list  of 
routine  associated 
er  and  assign  the 
lly,  the  last  token 
an  program  for  the 


iage  return,  a  line 
and  indicates  that 


1 


v. 2  Parsing 


80 

the  end  of  line  has  been  reached.  The  scanner  returns 
the  list  of  tokens  which  it  has  constructed. 

2.  break:  When  a  control-B  is  detected,  the  RUTGERS/UCI 
LIS?  break  package  is  entered  in  which  the  user  has  full 
use  of  LIS?.  The  current  token  will  be  set  to  the  value 
returned  from  the  break. 

3.  abort:  A  control- A  will  cause  the  current  parse  to  be 
a  bo r ted . 

4.  delete:  Control-D  causes  the  deletion  of  the  previous 
token. 

5.  edit:  when  control-E  is  typed,  the  user  will  be  able  to 
edit  his  input  list  after  the  next  end  of  line. 

6.  fill:  The  character  control-N  indicates  that  the  next 
token  is  the  name  of  a  variable  referencing  a  list  of 
valid  tokens.  This  list  is  appended  to  the  list  that 
the  scanner  is  building,  and  the  combined  list  is 
returned  to  "ADVANCE".  This  action  must  be  the  last  on 
a  line. 


Associated  with  each  of  the  128  ASCII  characters,  in 
addition  to  the  scan  programs,  is  a  type.  These  types  are  used 
by  the  scan  programs;  for  example  the  letters  are  of  type 
"LETTER".  Characters  which  appear  only  as  single  character 
tokens  have  as  their  types  their  token  representation,  and 
control  characters  have  as  their  types  LISP  atoms  which  have  a 
"CONTROL:"  property  on  their  property  lists.  The  scan  program 
for  single  character  tokens  simply  returns  the  type  of  that 
character.  The  program  for  a  letter  will  read  letters  until  a 
token  whose  type  is  not  "LETTER"  or  "NUMBER",  creating  a  LISP 
atom  from  these  characters.  If  such  an  atom  has  a  "KEYWORD:" 
property,  the  atomic  token  for  that  keyword  is  returned. 
Otherwise,  the  token  "  (NAME  .  <atom>) "  is  returned.  For 
characters  which  begin  other  composite  tokens  (for  example. 
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,  the  type  is  necessary  only  to  indicat 
for  scanning  names  and  numbers  that  the 
belong  to  such  tokens. 

V. 2. 3  Parsing 

The  translator  operates  in  two  stages, 
(the  parser)  produces  an  intermediate  str 
the  second  stage  in  creating  the  objects 
input.  The  major  concerns  of  the  parser  ar 
external  names,  interactive  error  correct 
forms  for  primitive  operations.  The  second 
the  relevant  primitive  routines. 


The  output  of  the  parser  is  a  LISP  s-ex 
be  used  as  a  parameter  to  a  routine  which  c 
the  knowledge  base.  This  allows  changes  to 
reguiring  changes  to  the  rest  of 
communication  through  the  internal  represen 
is,  however,  reguired.  Firstly,  the  parser 
external  names  of  an  object  as  a  value  on  th 
the  LISP  atom  representing  it.  Secondly,  to 
to  uncreated  objects,  the  parser  may  pass  at 
routine  which  are  to  be  used  as  locati 
objects  which  are  to  be  created.  For  exampl 
in  a  program  references  a  parameter,  a  slot 
be  generated  containing  the  internal  name  of 
the  parser  generates  a  name  for  that  class 
can  pass  the  completed  slot  specificatio 
instructions  for  creating  the  entire  class. 
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eractive  error  correction  is  possible  because  each 
is  require!  to  store  the  current  status  on  a  parse 
If  an  error  occurs,  the  user  can  restore  the  status  at 
qher  point  in  the  parse  tree  and  re-start  execution  at 
ction  after  editing  the  input  list.  An  error  handling 
is  provided  which  has  commands  for 


1.  changing  the  state  to  some  previous  non-terminal, 

2.  inserting  and  deleting  tokens  from  the  input  list  at 
that  point,  and 


3. 


causing  execution  to 


restart 


at  that 


point. 


The  last  feature  depends  heavily  on  the 
evaluation  mechanism  and  is  not  portable. 


F.DTGEE  S/UC I  LIS? 


The  parser  also  includes  some  functions  which  take  as 
arauments  structures  returned  by  the  functions  for 
non- terminals  of  the  grammar  and  rearrange  or  add  to  these 
structures.  The  most  important  of  these  is  an  1EXPF  called 
"FOE?!".  This  takes  as  arguments  the  name  of  a  primitive 


function 

(for 

example,  ADD) 

and 

an  arbitrary  number 

of 

s- expres  si 

ons 

representing  pa 

rsed 

expressions  which  are  to 

be 

arguments 

of 

the  primitive 

function.  From  these 

an 

s-expressior  is  made  which  will  result  in  a  form  whose  "eval" 
properties  are  the  forms  resulting  from  the  argument 
expressions  and  which  has  as  a  "returns"  statement  a  call  to 
the  primitive  operation.  The  next  section  will  describe  how 
the  interpreter  handles  such  rorms. 
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V. 3.  Interpreting 

V. 3.  1  Introduction 

The  interpreter  is  the  routine  which  deciphers  the 
structure  of  PSN  programs  and  forms  to  cause  changes  in  the 
knowledge  base.  It  therefore  implements  programs  as  they  were 
described  in  chapter  three.  The  important  issues  are  the 
implementation  of  the  relation  ”  dynamic*' ,  the  mechanism  for 
returning  values,  the  means  by  which  a  generator  can  be  created 
and  detached  (returning  a  value)  ,  parameter  evaluation, 
variable  binding,  and  execution  of  forms  which  are  the  ,!eval" 
property  values  of  slots. 

At  some  level,  the  "eval"  links  will  point  to  primitive 
forms  which  are  black  boxes  to  PSN.  The  system  represents 
these  forms  as  LISP  s-expressions  which  are  simply  given  to 
EVAL  in  LISP.  These  LISP  s-expressions  are  recognized  as 
instances  of  the  class  "FORM  H ,  thus  they  may  be  validly  used  as 
"eval"  property  values.  The  input  language,  however,  does  not 
give  the  user  the  ability  to  directly  create  such  forms. 
Therefore,  they  appear  only  where  generated  by  the  parser  to 
implement  expressions  and  in  the  special  predefined  programs 
which  will  be  discussed  in  the  following  sections. 


The  LISP  forms  generally  acquire  their  actual  parameters 
from  the  PSN  forms  which  invoke  them.  The  mechanism  for  doing 
this  is  a  function  known  as  ’’PARAM-EVAL1'  which  takes  an 
external  slot  name  as  a  parameter  and  finds  the  corresponding 
property  value  of  the  most  recent  PSN  process.  Figure  5-1 
shows  how  a  form  calling  a  LISP  expression  is  represented.  The 
form  "  A  DDO  1 19  will  return  the  result  of  adding  95  to  116.  The 
system  avoids  having  to  have  an  explicit  instance  of  the  class 
"PROGRAM"  for  each  primitive  function  by  creating  the  forms 
independently  of  such  programs.  "ADDOI"  is  therefore  not  a 
subclass, of  any  program. 
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V. 3. 2  The  Interpreter  loop 


The  basic  structure  of  the  interpreter  is  a  loop  which 
continues  until  the  processes  on  the  dynamic  chain  are  executed 
to  completion.  At  the  beginning  of  an  iteration,  the  process 
under  consideration  is  known  as  the  current  process.  Each 
process  has  associated  with  it  a  system  property  known  as 
"STATE: l!  which  consists  of  a  list  of  the  slots  not  yet 
executed,  with  prerequisite  slots  preceding  the  body  slots 
which  precede  the  "returns"  slot.  Another  system  property  Is 
the  "CURRENT-SLOT:".  If,  at  the  beginning  of  an  iteration, 
there  are  no  slots  remaining  in  the  "STATE:",  the  returned 
value  of  the  current  process  becomes  the  value  of  the  property 
indicated  by  "CURRENT-SLOT:"  of  the  predecessor  process  in  the 
dynamic  chain.  Also,  the  current  process  is  killed,  and  the 
predecessor  becomes  the  new  current  process. 


If  at  the  beginning  of  an  iteration,  the  "STATE:"  is  not 
empty,  the  first  slot  in  this  state  becomes  the  current  slot 
and  the  state  list  is  popped.  At  this  point  one  of  the 
following  four  alternatives  is  possible: 

1.  the  current  slot  is  a  "quote_paramete rs"  slot  and  has  a 
quote  property  value;  this  value  becomes  the  current 


slot 

property  value  of  the 

curren  t 

process ; 

2. 

the 

slot  has  an  "eval" 

property 

value  which 

is  a  LISP 

f  orm 

;  this  is  evaluated  using 

the 

LISP  EVAL 

and  the 

returned  value  becomes 

the 

property  value 

of  the 

process ; 

3. 

t  he 

"eval"  value  is  a  PSN 

form 

;  the 

actions  are 

create  a 

new 

process  and  make  It 

an 

instance  o^  the  form. 

evaluate  the  parameters. 

assert 

the  dynamic 

relation 

with 

the  current  process. 

and 

make 

the  new  process  the 

current  process; 

4.  in  all  other  cases,  the  value  "unknown"  becomes  the 
property  value  for  the  current  slot. 
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few  special  PSN  objects  whose  associated  forms 
book-keeping  actions  for  the  interpreter. 
1  often  be  included  in  the  state  of  a  process 
o  not  appear  in  the  corresponding  program, 
olve  fiddling  with  the  relation  "dynamic"  and 
in  the  following  subsections. 


V.3. 3  Dynamic  and  Parameter  Evaluation 
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1 . 


an  atom  in  the  a-list  is  called  a  block.  When 
interoreter  reaches  a  block,  instead  of  assigning 
value  to  be  returned  to  a  previous  process,  it  retu 
the  value  as  a  LISP  function.  This  allows  primit 
functions  to  invoke  the  interpreter. 

oairs  of  the  form  "  (XXXX  .  <process>)  "  are  ignored 
most  routines.  In  oarticular,  processes  on  either  s 
of  such  a  oair  are  considered  an  assertion  of  ’’dynami 
Such  pairs  become  regular  pairs  when  the  current  slot 
an  instance  of  the  class  "restore".  This  slot  cau 
the  relation  "dynamic"  to  be  asserted  between 
process  in  the  special  pair  and  that  preceding  it. 
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which  these  values  are  being  computed. 

7.3.4  Detaching  Processes 

A  second  special  command  in  the  state  of  a  process  Is  the 
object  ">exit-slot"  which  causes  the  actions  of  the  program 
'•DETACH'1  to  be  performed.  When  this  is  the  current  slot,  the 
following  actions  occur: 

1.  the  first  instance  of  the  program  which  is  the  value  of 
the  "label"  property  of  the  current  process  (which  is  an 
instance  of  "DETACH")  Is  disconnected  from  its  calling 
process  (that  is,  the  assertion  of  "dynamic"  between  the 
two  is  removed) , 


2. 

the  valu 

e  of  the  "return" 

proper! y 

of 

the 

current 

p  rocess 

becomes  the  value 

returned 

to 

the 

calling 

process  of  the  detached  process,  and 

3.  the  current  process  is  killed. 

Since  "dynamic"  is  implemented  as  a  list,  the  Dart  which  is 
removed  when  the  link  is  broken  in  step  one  must  be  stored  with 
the  state  of  the  process. 


The 


is 

used 

curr 

ent 

valu 

e  t 

nrer 

equi 

occu 

rs. 

only 

whe 

whose  ad 

final  special  object  is  known  as  " >break-s lot"  which 
to  set  up  a  generator.  When  this  is  encountered,  the 
process  is  detached,  and  the  process  object  becomes  the 
o  be  returned.  A  break  is  usually  placed  after  the 
site  evaluations  of  a  generator  so  that  when  the  break 
one  has  a  valid  process.  A  process  is  made  a  generator 
n  it  is  created  through  the  special  class  "GENERATOR" 
d  program  is  capable  of  insert  In g  the  break. 


V.3.5  Exception  Handling 


Checking  of  a 
to  make  a  value  the 
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value  of  the  proper! 
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the  attempt  is  made 
y.  If  the  value 
guisites"  slot  the 
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V. 3  Interpreting 


exception  handling  mechanism  becomes  active.  This  mechanism  is 
implemented  exactly  as  described  in  chapter  two. 

V . 4 .  Predefined  Programs 


The  predefined  programs  are  the  means  by  which  the  major 
control  structures  of  the  PSN  language  are  implemented.  For 


example,  the  expression  Mnew 
the  program  "NEW” . 


results  in  a  form  calling 


V.  4.  1  NEW 

Forms  which  call  "NEW”  are  used  to  begin  the  process  of 
creating  an  object.  Once  the  parameters  have  been  evaluated, 
the  creation  routine  described  in  chapter  four  can  be  invoked. 
The  interesting  problem  here  is  representing  the  parameters. 

The  object  to  be  created  may  have  an  arbitrary  number  of 
types.  Therefore,  the  form  has  one  "instance-of "  parameter 
which  is  expected  to  be  a  LIS?  list  of  forms  which  will 
evaluate  to  classes.  Similarity,  the  "isa"  parameter  requires 
another  list  of  forms  which  will  evaluate  to  classes.  Thus  the 


ons 

of  " 

NE 

W "  include  routi 

nes  for 

evaluatin  g 

each 

of  the 

s  in 

these 
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ists . 

The 

"with 

M 

parameter  of  the 

program 

requires  a 

still 

more 

lex 

data 

t 

ype.  This  is  a 

list  of 

ordered  pai 

r s  of 

which 

the  first  element  is  the  external  name  of  a  property,  and  the 
second  element  is  a  form  which  can  be  evaluated  to  produce  a 
property  value  for  the  new  object.  Before  "NEW”  can  start  the 
creation  process  it  must  create  a  similar  list  with  the  values 
of  the  forms  replacing  the  forms. 


description  of 


The  most  complex  of  the  parameters  is  that  which  expects  a 

the  structure  of  a  class.  Here,  a  list  of 
descriptions  of  slots  must  be  passed  to  the  creation  routine. 
Each  slot  descriptions  contains  a  number  of  forms  each  of  which 
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must  be  replaced  by  a  value  by  "NEW".  A  s 
also  contain  a  structure  description  (i 
metaslot),  which  requires  a  recursive  ca 
formation  routine. 


lot  description  may 
f  the  slot  is  a 
11  to  the  structure 


V .  4 . 2  RUN 


The 
the  pro 
para  mete 
of  the  " 

which  s 
paramete 
interpre 
prod  uced 


PSN  program  ,,RTJN,f  is  used  to  create  a  form  which  calls 
gram  specified  as  the  argument  "program "  with  the 
rs  bound  as  specified  by  the  argument  ‘'with".  The  form 
with"  argument  is  a  list  of  pairs  of  the  form 


"  (<parameter-name>  .  <form>)  " 
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variable . 


also  used  when 


the  program  to 


be  called  is  a 


V.4.3  Other  Predefined  Programs 

The  program  "BEGIN"  is  supplied  to  implement  begin-end 
blocks  exactly  as  described  in  section  3.5.  The  algorithm 


is 


QQ 
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simply  t 
of  the  p 
value  pr 


o  return  the  value 
arameter  ,,arg2M  is 
oduced  by  interpret 


of  the  parameter 
" NULL_FORM " ,  oth 
ing  the  value  of 


"arg  1" 
erwise 
"arg2" 


if  the  value 
return  the 


Another  important  control  structure  implemented  by  a 
program  is  conditional  evaluation.  The  program  "IF"  takes  four 
parameters:  "condition"  which  is  a  Boolean  value,  and  "true", 
"false",  and  "unknown"  which  are  forms.  The  value  returned  by 
"IF"  is  that  produced  by  interpreting  the  form  which  is  the 
value  of  the  slot  indicated  by  the  value  of  the  "condition" 
parameter.  For  example,  if  the  value  of  the  condition  is  true, 
the  form  "true"  is  evaluated.  etc. 


The  final  ?SN  control  structure  is  the  for- loop.  This  is 
implemented  bv  forms  calling  two  programs.  The  first  form  is  a 


call  to 

the 

p  r  o  g  ra  m 

"FOP -LOOP"  which 

"aenerat 

or" 

of  type 

"GENERATOR",  and 

"FORM". 

The 

second  form  is  a  call  to  th 

has  two 

pa 

rame ters : 

"self"  which  is  a 

value  is 

any 

ob  ject . 

This  form  is  the  " 

the  returns  slot  of  the  first  form. 


The  set  of  forms  which  make  up  a  typical  for-loop  are 
illustrated  in  by  the  example  in  figure  5-2.  When  the  loop  is 
entered,  the  "eval"  property  of  "generator"  results  in  the 
creation  of  a  new  generator.  The  call  to  "FOE-BODY"  is  then 
begun:  the  parameter  "x"  In  the  example  illustrates  the 
parameter  which  was  not  named  above  and  is  used  as  the  loop 
variable.  It  gets  its  value  through  the  evaluation  of  a  call 
to  "GET"  which  simply  attaches  the  generator  and  interprets  it. 
It  returns  the  value  returned  when  the  generator  detaches. 


The  first  action  in  the  execution 
apply  the  interpreter  to  the  value  of  "code 
gene  rat o  r  is  dead  {that  is,  no  objects  rem 
the  generator)  it  returns  the  value  returned 
of  "code".  Otherwise  it  returns  the 
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".  Next,  if 
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value  returned 
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_F OR- LOOP 
parameters 

generator  a - type- - ^GENERATOR 

code  » - type - — y»FORM 


figure  5-2 
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interpreting  the  form  which  is  the  value  of  ’’self" .  If  the 
value  of  "self"  is  the  form  of  which  the  process  is  an 
instance,  the  effect  will  be  the  evaluation  of  the  form  "code" 
until  the  generator  is  exhausted. 


CHAPTER  VI 
Examples 


VI. 1.  Introduction 

This  chapter  illustrates  the  use  of  the  new  language 
features  in  the  writing  of  programs.  At  the  present  time,  the 
implementation  Is  not  complete  and  therefore  actual  computer 
runs  are  not  possible.  The  examples  which  this  chapter 
provides  were  chosen  because  they  illustrate  both  interesting 
language  features  and  the  fact  that  a  reasonably  sized 
implementation  of  the  interpreter  can  be  written  within  the  PSN 
language . 

VI. 2.  lists 


In  many  of  the  predefined  programs  presented  in  chapter 
five,  one  finds  that  the  parameters  reguire  a  list  of  objects. 
The  computer  implementation  used  the  LIS?  list  structure  for 
such  parameters  because  the  programs  were  usually  implemented 
through  LIS?  functions  which  operate  efficiently  on  such 
structures.  The  first  example  in  this  chapter  will  illustrate 
how  lists  and  a  routine  to  create  them  may  be  written  in  PSN. 
Figure  6-1  Illustrates  a  pair  of  cla sse s  wh ich  implement  the 
general  list  data-type.  A  list  is  either  a  " LI ST_EL EHENT" 
which  is  an  object  with  a  pointer  to  an  element  of  the  list  and 
a  pointer  to  the  next  "LIST_ELEMENT" ,  or  the  special  object 
"NIL1'.  Thus  the  representation  for  the  list  "{a  b  c)  M  is  that 
illustrated  in  figure  6-2.  Figure  6-3  shows  that  one  can 
restrict  the  elements  of  a  list  to  be  a  given  type  by  giving  a 
less  general  type  to  the  "first"  slot.  In  this  case  the  class 
"PERSON_LIST"  is  a  class  of  lists  whose  elements  are  people. 
Figure  6-4  shows  the  parts  of  the  respective  programs  which 
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figure  6-3 
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figure  6-4 
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change  as  PSN  objects  to  demonstrate  that  " PERSON_LIST "  is  a 
valid  specialization  of  "LIST”. 

A  list  set  up  in  this  way  is  very  similar  to  a  list  in 
LISP.  If  "list"  is  an  instance  of  » LIST_ELL  MENT " ,  then  "list  $ 
.first”  (the  value  of  the  ’’first"  property  of  the  object 
"list”)  corresponds  to  the  LISP  expression  "(CAR  list)",  and 
"list  $  .rest"  corresponds  to  ”  (CDR  list)”.  The  object  "NIL" 
is  a  special  list  element  which  signals  the  end  of  a  list.  It 
is  defined  so  that  "NIL  $  .first"  and  "NIL  $  .rest”  are  both 
egual  to  "NIL".  The  need  for  the  special  class  "LIST"  arises 

for  typed  lists  -  one  would  like  a  unique  object  for  "NIL", 

but  if  a  list  is  typed,  the  general  "NIL"  will  not  be  an 
instance  of  the  list  element  class  for  that  type  of  list  (this 
can  be  seen  in  figure  6-3). 

The  following  is  a  routine  which  might  be  used  by  the  add 
program  of  the  class  "LIST".  The  following  points  should  help 
clarify  the  example: 

1.  keywords  of  the  language  are  underlined  in  this  chapter 
to  increase  readibility. 

2.  the  keyword  "program"  is  an  abbreviation  for  "new 
PROGRAM  structure"  which  means  create  a  new  instance  of 
the  class  "PROGRAM"  having  the  structure  indicated. 

3.  the  names  "parameters",  "body",  and  "returns"  ar^  used 
to  indicate  that  the  slots  listed  following  each  name 
are  instances  of  that  metaslot  of  the  class  "PROGRAM". 

4.  a  slot  is  defined  by  the  construction  "name  :=  a  type, 
tvpe,  ...  with  etc."  The  construction  "name: type, 
type,  ...:forra;  with  ..."  is  an  abbreviation  for  "name 
:=  a  type,  type,  ...  with  eval  <-  [form],  ..." 

5.  the  returns  slot  may  not  cause  any  side  effects,  so  one 
often  finds  that  it  simply  returns  the  value  of  one  of 

{  Re?  t>.iU  v  -.let-.  (In  (hi-:  v-.-i  i,e  "hi")  . 
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6. 


the  construct 
generator  is 
generator  has 


ion  *’£Gt  generator”  indicates  that 
to  run  and  return  the  next  value.  If 
been  terminated,  the  expression  fails. 


the 

the 


make_list  :=  program 
parameters 

g  : =  a  GENERATOR  end  slot 
body 

b 1 : OBJECT: 

if  (dead  g) 
true 
NIL 
false 

new  LIST_ELEMENT  with  first  <-  get  g,  rest  O 
run  make_list  with  g  <-  g 
end  if, ; 
end  slot 
returns 

r 1 : OB JECT : b 1 ;  end  slot 
end  program 


This  routine  takes  each  element  returned  by  the  generator  and 
includes  it  in  the  list.  For  a  call  to  the  add  program  of 
’’LIST”  (for  example,  "new  LIST  with  generator  <-  new  GENERATOR 
with  class  <-  some_class  end  end”),  the  routine  ”make_list” 
would  be  called  with  the  generator  supplied  in  the  "new11 
statemen t . 


VI. 3.  Finding  Variable  Values 


An  important  aspect  of  PSN  programs  is  the  use  of  slots 
variables  and  property  values  as  slot  bindings.  The  example 
this  section  is  a  function  which,  given  a  slot  and  a  start 
point  on  the  dynamic  chain,  will  find  a  property  va 
corresponding  to  the  slot,  in  effect  locating  a  value  bound 
a  variable.  The  function  ” f ind_slot_value”  implements  such 


as 

of 

ing 

lue 

to 

a 
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search. 


f  ind_slot_value  :=  program 
paran  eters 

process  :=  a  PROCESS  end  slot 

variable  :=  a  slot  end  slot 
body 

b 1 : OBJECT : 
begin 

locals 

part  :=  a  slot  end  slot 
end  locals 

for  tvpe_of  in  type  process  _do 

if  ?A?.T_OF  :  :  variable  ?  type_of  and 
Dart  =  unknown 
true 

part  <-  type_of 
end  if 
en3  For 

if  ?AET_OF  : :  variable  ?  part 
true 

process  s  variable 
false 

eval  f ind_slot_value  w ith  process  < -  for  y  in 
dynamic  (process)  do  y  end,  variable  <- 
variable 
unknown 

unknown 
enf_  if 
end  begin ; 
end  slot 
returns 

r 1 : OBJECT : b 1 ;  end  slot 
end  propram 
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This  example  illustrates  the  following 


points: 


1.  there  is  no  special  syntax  for  fetching  unique  objects. 
Thus,,  when  one  desires  to  find  the  range  instance  of 
some  assertion  of  •’dynamic” ,  it  is  necessary  to  use  a 
for-loop  (for  example,  "for  y  in  dynamic  (process) 

2.  since  objects  may  have  more  than  one  type,  operations 

using  types  must  use  a  for-loop  with  a  tvpe  generator 
("for  y  in  type  process  This  operation  returns 

only  the  non-redundan t  set  of  types,  not  the  entire  set. 
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The  example 
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have  been  left  out 
shorter.  The  more 
text  following  the 


of  this  section 
PSN  interprete 
of  the  example 
important  omis 
program. 
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interpreter  :=  E£opram 

curren t_slo t  :=  a  slot  end  slot 
returning  :=  an  OBJECT  end  slot 
return_slot  :=  a  slot  end  slot 
pr evious_process  :=  a  PEOCESS  end  slot 
param  eter s 

curr ent_process  : =  a  PROCESS  end  slot 
body 

bo  dy_slot : OBJECT: 

for  y  in  state  (cur ren t_process)  dp 
if  y=NIL 
true 

for  z  in  returns  do 

for  zz  in  type  cur rent_process  dp 

if  PAET_OF  : :  z  ?  zz  true  return_slot  <- 
end  if 


z 
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end  for 
end  for ; 

returning  <-  curren t_process  $  return_slot; 
f.or  2  in  dynamic  [c  urren  t_process)  do 
previous_process  <-  z 
end  for; 

kill  current_process; 

run  assign  with  process  <-  previous_processf 
value  <-  returning; 

run  interpreter  with  current_process  < - 
pre vious_process 
false 

current_slot  <-  y  $  .first; 
assert  CrJREENT_SLOT  :  cur rent_process  -> 
c  urrent_slot ; 

assert  state  :  curren t_process  ->  run 
pop_list  with  list  <-  y; 
if  current_slot  ?  quote_slot 
true 

run  assign  with  process  <- 
curren t_process ,  value  <-  current_slot  S 
.quote,  slot  <-  curren t_slot ; 
run  interpreter  with  current_pr ocess  <- 
current_process 
false 

if  current_slot  ?  action_slot 
true 

if  current_slot  $  .eval  ?  PRIMITIVE 
true 

run  assign  with  process  <- 
curren t_pr ocess ,  value  <-  run 
PRIM  with  form  <- 
current_slot  $  .eval; 
run  interpreter  with 
current_process  <- 
curren  t_pr ocess 


f  alse 


VJ 
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run  new_process  with 

form  <-  current_slot  t 
.eval,  oid_process  <- 
current_ process 
unknown 

run  assign  with  value  <~ 
unknown,  process  < - 
current_pr ocess 
end  if 

false 


run  assign 

with 

value  <-  unknown. 

process 

<- 

current_pr ocess 

unknown 

run  as si 

gn 

with 

value  <-  unknown. 

process 

<- 

curren  t_p r ocess 

end  if 

end  if 

end  if 
end  for; 
end  slot 
returns 

r 1 ; OBJECT ; b  1  ;  end  slot 


end  £123122 


The  major  problem  with  t 
recursive  program  which  has  no  te 
will  never  return.  A  solution 
which  would  be  assigned  the 
interpreter,  and  to  kill  this 
interpreting.  The  old  state  of  t 
be  retained. 


his  program  is  that  it  is  a 
rmination  condition,  hence  it 


to  this  is  to 
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calls 
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act  ion 

of 

he  Interpreter 

will 

then 

not 

The  programs  '’assign'1  and  "new_process" 
included  as  examples.  "assign"  assigns  the  value 
parameter  to  the  current  slot  of  the  process 


will  not  be 
given  as  a 
the  value 


which  Is 
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of  the  parameter  "process" 
check  that  value  assiqned  to 
If  the  prerequisite  value 
routine  described  in  the  next 


VI. 4  An  Interpreter 

.  It's  secondary  function  is  to 
prerequisite  slots  is  not  "false", 
is  false,  the  exception  handling 
section  is  invoked. 


The 

perform 
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routine  "new_process"  is  used  t 
the  parameter  evaluations,  and 
process  via  "dynamic".  The  para 
that  forms  be  interpreted,  but 
ter  never  returns  causes  pro 
d  by  providing  the  interpre 
r  which  would  take  as  its  value 
ional  to  halt  execution.  When 
cess  as  a  value,  a  value  would 
ter  to  the  routine  which  called 
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ter 
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be 
it. 


eate  a  new  process, 
the  new  process  to 
r  evaluations  will 
n  the  fact  that  the 
s.  This  can  be 
with  yet  another 
ocess  which  would 
current  process  has 
returned  by  the 


VI . 5 .  Except  ion  Handling 

This  section  describes  a  routine  which  implements 
exception  handling  as  described  in  chapter  three.  The  program 
is  given  first: 


exception_processor  :=  or oo m 


th e_exception  :=  an  EXCEPTION  end  slot 
ex  cept  ion_t  vpe  :=  an  EXCEPTIONAL  A  SS  end  slot 
calling_process  :=  a  PROCESS  end  slot 
call_handler  :=  a  FORM  end  slot 
ca 11 ina_slo t  :=  a  slot  end  slot 
the_handler  :=  a  PROGS AH  end  slot 
parameters 

bad_slot  :=  a  slot  end  slot 
bad_process  :=  a  PROCESS  end  slot 


body_slot  1  -.OBJECT: 
begin 

the  handler  <-  run  new  process  with  form  <- 
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(bad_slot  $  .exception)  ,  oH_process  <- 
bad_process ; 
the_except ion  <- 

interpret  [bad_slot  S  .exception); 
for  x  in  type  the_e xcept ion  do 
if  x  ?  EXCE?TION_CLASS 
true 

exception_ty pe  <-  x 
end  if 
end  for; 

for  x  in  dynamic  (bad_process)  do 
calling_process  <-  x  end  for; 
for  x  in  CURP.EMT_SLOT  (calling_process)  dp 
calling_slot  <-  x  end  for; 
for  x  in  slot  do 

if  PART_0 F; ;  x  ?  (ca 1 ling_sl ot  $ 

. e xcept ion_act ion ) 
true 

for  y  in  type  x  dp 

if  y  =  except ion_type  | 
except ion_ty pe  subclass  y 
true 

the_handler  O  x  S  .handler 
end  if 
end  for 

end  if 
end  for; 

call_handler  <-  new  FORI  isa  the_handler 
structure 

quote_parame ters 

exception  ;=  a  *  with  quote  O 
the_exception  end  slot 
end  new; 

kill  bad_process; 

run  new_process  with  form  <-  cal l_handler , 
old_process  <-  calling_process 
end  bepin 
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end  slot 
returns 

returns_slot:OBJFCT:bodv_slot1  en 1  slot 
end  program 


The 


routine 


u 


new  process 


ii 


is 


used 


twice 


m 


"exception_processor M  to  evaluate  forms.  This  is  used  instead 
of  the  11  interpret 11  command  because  the  new  process  must  be 
attached  to  the  user's  dynamic  chain,  not  that  joining  the 
urocesses  of  the  interpreter.  The  second  call  to  "nev_process" 
is  preceded  by  an  explicit  creation  of  a  form  in  which  one  of 
the  Darameters  is  assigned  a  "quote"  property.  The  star  {"*"1 
in  the  type  of  the  slot  indicates  that  the  types  are  to  be 
inherited  without  modification.  This  creation  is  necessary 
because  once  execution  of  the  form  calling  the  handler  begins, 
any  reference  to  the  variables  in  "e xception_processor"  cannot 
be  resolved  because  the  variable  binding  mechanism  will  search 
the  user's  dynamic  chain.  The  expression  "isa  the_handler"  is 
what  makes  the  form  a  call  to  the  exception  handler. 

Once  the  handler  has  been  run,  control  is  returned  to  a 
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VI. 6.  Us 

in 

q 

Exceptio 

ns 

This  section  shows  proqram  fragments  which  associate  an 
exception  to  a  a  prerequisite  and  a  calling  program  with  a 
corresponding  exception  handler  link.  The  context  used  for  the 
examples  is  that  of  an  airline  reservation  in  which  a  flight 
may  have  been  booked  to  capacity  {this  is  the  context  op  the 
example  in  [ Xylopoulos  et  al.  1QT8]). 
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First  the  exception  class  no  seats  left  is  associated  with 
a  corresponding  prerequisite  of  the  reservations  program. 


reserve_seat  :=  program 

•  •  9 

prerequisites 

check_seats : BOOLEAN : 

flight  $  . number_seats_lef t  >  0; 

with  exception  <-  [ new  NO_SSATS_LEF!  with 
flight  <-  flight,  person  <-  person] 
end  slot 

•  ®  • 

end  program 


The  program  to  reserve  a  seat  on  a  flight  can  be  called  by 
a  program  which  arranges  a  trip  to  Europe.  The  next  program 
fragment  shows  the  association  of  a  handler  to  the  exception. 


arrange_europe_tr ip  :=  program 

•  •  • 

body 


ge  t_re  serva  tion : OB JECT : 

run  reserve_seat  with  flight  <-  flight,  person  <- 
client ; 

with  exception_act ion  <- 

new  EXCEPTION_HANDLEF._LINK  structure 

eh  1  : =  a  NO_SEATS_LEFT  with  handler  <- 
FIND_ AL TERN  ATT VE 
end  slot 
end  new 
end  slot 


end  program 
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This  piece  of  code  attaches  an  exception  handler  link  to 
the  slot  "get_reservation" ;  the  action  to  be  performed  when 
"NO_SSATS_LEFT"  is  raised  is  " FIN D_ ALTER N  ATIVE"  which  should 
perform  appropriate  actions  to  maintain  consistency  in  the 
knowledge  base.  The  program  "reserve_seat "  will,  however,  be 
called  from  the  form  representing  the  call  to  "RUN",  and  from 
the  strict  interpretation  o^  the  exception  handling  mechanism, 
the  handler  for  the  exception  raised  in  " reser ve_seat"  must 
therefore  be  supplied  by  "RUN".  This  problem  is  handled  by 
giving  the  interpreter  knowledge  of  the  special  forms  which 
reguire  that  exception  handler  links  be  inherited. 


This  solution  is  especially  necessary  in  the  case  of  begin 
blocks  because  such  structures  expand  into  many  forms.  ^igure 
6-F  illustrates  a  sequence  of  forms  in  a  begin-end  structure 
for  which  an  exceDtion  handler  link  is  specified  for  the  slot 
calling  this  structure.  The  dotted  arcs  illustrate  the 
effective  inheritance  of  the  link.  The  exception  handlers  are 
therefore  specified  for  each  form  in  the  block. 
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figure  6-5 


CHAPTER  VII 
Conclusion 


VII.  1.  Summary. 

This  thesis  consists  of  three  parts:  a  brief  survev  of  the 
current  state  of  the  procedural  semantic  network  formalism, 
proposals  for  new  mechanisms  which  are  useful  in  organizing 
knowledge,  and  a  description  of  a  computer  implementation  of 
the  formalism. 

At  the  time  of  writing,  the  computer  implementation  of  PSN 
is  not  yet  completed.  What  presently  exists  is: 

1.  a  parser  for  the  language  described  in  appendix  1  and  a 
routine  for  converting  the  output  of  the  parser  into  PSN 
forms ; 

2.  standard  add,  fetch,  test,  and  kill  proarams  for 

relations  and  classes; 

3.  mechanisms  for  defining  and  inheriting  structure  and 
m etastruct are ; 

4.  routines  for  asserting  and  retrieving  slot  values;  and 

5.  an  interpreter  for  PSN  programs. 

Work  to  complete  the  implementation  and  improve  the  formalism 
is  continuing. 
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VIT.2.  Contributions 


One  of  the  original  contributions  of 
([Levesque  1977  ])  was  to  provide  progra 
structure  in  the  hope  that  this  would  sirapli 
task  and  make  programs  easier  to  understand 
further  in  this  direction  by  improving  the 
declarative  structure  of  programs  intera 
hierarchy.  Programs  are  more  easily  under 
conseguences  of  each  distinct  unit  (a  form 
of  a  program  can  be  considered  in  isolation 
Programming  for  complex  problems  is  sim 
inheritance  mechanism  allows  programs  to 
specific  tasks  through  the  specifica 
differences  in  the  task.  Finally,  the  inte 
of  specialization  in  terras  of  net  side  effec 
maintenance  of  a  consistent  knowledge  base. 


the  PSN  for  mat  ism- 
ms  with  declarative 
fy  the  programming 
.  This  thesis  goes 
way  in  which  the 
cts  with  the  IS-A 
stood  because  the 
attached  to  a  slot) 
from  the  others, 
plified  because  the 
be  specialized  to 
tion  of  only  the 
nsional  definition 
ts  is  useful  in  the 


det astr uct ur e  is  introduced  into  PSN  as  an  extension  to 
the  organizational  tools  provided  by  the  formalism.  The 
ability  to  distinguish  slots  and  to  constrain  the  definitions 
of  properties  found  immediate  use  in  the  description  of 
programs.  The  introduction  of  this  new  concept  differs 
slightly  from  other  extensions  to  PSN  in  that  it  requires  a 
minor  modification  in  the  original  PART-OF  mechanism.  On  the 
other  hand,  one  could  have  introduced  both  metastructure  and 
Devi  rules  constraining  the  definition  of  slots  defined  in  terras 
of  the  old  mechanism  which  would  remain  in  the  background. 


A  computer  implementation  of  the  formalism  provides  a 
means  by  which  the  ideas  of  PSN  may  be  tested.  Once  this 
implementation  is  complete  it  will  be  possible  to  discover  the 
strengths  and  weaknesses  of  the  formalism  through  the  use  of 
working  knowledge  bases.  One  will  be  able  to  test  the 
usefulness  of  extensions  to  PSN  through  actual  programming  of 
these  extensions.  The  implementation  has  already  demonstrated 
the  compactness  of  PSN  because,  although  a  large  number  of 
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primitive  LIS?  functions  have  been  written,  the  system  depends 
on  a  very  small  number  of  primitive  operations  which  are  used 
by  the  more  complex  tasks. 

VII. 3.  Directions  for  Further  Work 


The  problems  which  have  yet  to  be  solved  can  be  divided 
into  three  areas:  additions  to  the  system  and  language  to  make 
it  more  habitable,  inclusion  of  existing  features  of  PSN  not 
vet  implemented,  and  theoretical  problems  and  additions  to  the 
PSN  formalism  itself. 


In  the  first  category,  an  important  addition  w 
routine  for  producing  a  readable  (paragraphed)  ou 
input  language  which  can  presently  be  printed,  only  a 
of  tokens.  A  related  problem  is  producing  a  readab 
of  the  contents  of  the  knowledge  base.  One  possibil 
direction  is  to  represent  objects  by  some  input  s 
would  create  that  object  in  the  context  of  the  know 
already  printed.  This  representation  would  of  cou 
be  paragraphed. 


ould  be  a 
tput  of  the 
s  a  stream 
le  printout 
ity  in  this 
tring  which 
ledge  base 
rse  have  to 


An  important  flaw  in  the  lan 
inability  to  exit  for  loops 
structure  such  as  "out  with  value 
[levesgue  1977].  For  loops  would 
with  which  more  than  just  the  ind 
one  iteration  to  the  next.  This 
properties  to  the  local  variables 
the  start  of  each  iteration 
created) .  A  third  improvement  t 
mechanism  for  attaching  exce 
individual  forms  in  a  begin  block 


guage  as  implemented  is  the 
prematurely.  This  reguires  a 
<-  ..."  as  introduced  in 

also  benefit  from  a  mechanism 
ex  variable  could  change  from 
might  be  done  by  adding  "eval" 
which  would  be  computed  at 
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when  a 
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Many  aspects  of  the  PSN 
successfully  implemented.  The 
IS-A  inheritance  between  forms 


formalism  have  not  yet  been 
exception  handling  mechanism  and 
have  not  yet  been  tested.  The 
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behaviour  of  the  third  Boolean  value, 

been  specified. 

"unknown" , 
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not 

yet 

The  restriction  mechanism  of 

PSN  has 

not 

yet 

been 

incorporated  into  the  implementation. 

to  be  answered  for  restrictions  are: 

Questions 

tha  t 

have 

yet 

1.  What  is  a  restriction?  Is  a  restriction  a  predicate, 
and  if  so,  how  many  arguments  does  it  have? 
Alternatively,  a  restriction  might  be  a  form.  In  this 
case  it  must  be  decided  what  slots  it  mav  reference. 

2.  When  is  a  restriction  applied?  The  restrictions  on  the 
slots  of  a  class  could  all  be  applied  to  an  instance 
before  the  add  program  is  run  or  when  the  add  program  is 
complete.  Alternatively,  a  slot  restriction  could  be 
applied  when  a  value  is  assigned  to  the  slot. 

3.  What  does  the  restriction  mean?  The  restriction  could 
cause  instantiation  to  fail  if  an  incorrect  value  is 
given  for  a  property.  Restrictions  could  also  be  used 
to  compute  the  values  of  a  slot  given  values  for  the 
other  slots. 
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s  of  PSN  which  have  yet  to  be  included  in  the 
re  the  lattice  restrictions  and  automatic 
t  classes  described  [Schneider  73a];  the 
finite  objects  described  by  D.  Berlin  ([Berlin 
tatic  exception  handling  mechanisms  described 
1980 j.  Also  the  concept  of  context  which  has 
theme  in  PSN  ([Levesque  1977  ],  [Schneider 
er  1979  ])  has  not  yet  been  included  in  the 


Finally  there  are  problems  within  the  formalism  which 
reguire  attention.  One  would  like  the  inheritance  of  property 
values  to  be  stronger  and  apply  a  uniform  IS-A  constraint  on 
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VII. 4.  Concluding  Remarks 

Although  a  number  of  problems  remain  to  be  solved,  both 
within  the  formalism  and  in  the  implementation,  PSN  is  evolvincr 
into  a  powerful  tool  for  the  representation  of  knowledge. 
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APPENDIX  1 
Grammar 


A  1 .  1 .  Introduct ion 

This  appendix  gives  a  complete  syntax  f 
currently  supplied  by  the  implementati 
includes  some  notes  on  the  meanings  of  the  v 

The  notation  used  for  describing  t 
modified  Bachus-Naur  form  for  which  the  diff 

1.  The  metasymbols  are  '  =  I)  [  ]  0  "  *  '  and 

2.  Terminals  are  always  enclosed  in  qu 
non-terminal  is  any  string  of  charac 
any  of  the  metasymbols. 

3.  The  metasymbol  '=’  is  used  to  replace 

4.  Concatenation  is  indicated  by  blan 
precedence  than  alternation  which 
commas.  Except  at  the  top  l^vel 
alternatives  is  enclosed  in  braces 

5.  Zero  or  one  occurrence  of  a  term  is 
brackets  ( 1 [  ] f ) . 


or  the  PSN  language 
on.  Each  section 
arious  constructs. 

he  language  is  a 
erences  are: 


the 

blank. 

otes 

('’)  ,  whereas  a 

ters 

delimited  by 
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ks  and  has  a  higher 
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of  a 

rule,  a  set  of 

0  ') 

• 

enc 

lose!  in  square 

A  1.2.  Names  and  Constants 

In  the  input  stream  a  name  is  a  sequence  of  characters 
beginning  with  a  letter  and  followed  by  any  number  o'  letters, 
digits,  or  underscores  (’’)•  Any  other  character  will  stop  the 
scanning  of  a  name.  A  name  in  a  PSN  program  has  one  of  two 


A  1.2  Names  and  Constants 
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meanings:  it  is  either  a  reference  to  a  slot  value  if  it  names 
a  slot  defined  in  some  program  statically  containing  the  form 
in  which  the  name  appears,  or  it  is  a  external  name  of  some 
object  in  the  knowledge  base. 


Constants  which  are  allowed  in  PSN  are  the  tokens  "true”. 


"false" , 

and  "unknown". 

strings,  and  numbers. 

A  string  is 

a 

sequence 

of  any 

characters  except  the  quote  (")  which 

is 

enclosed 

in  quotes. 

A 

number  is  a  sequence  of 

digits  which  m 

ay 

optional 

ly  include 

one 

period  representing  the 

decimal  point. 

A  1 . 3 .  Sx 

pression  s 

This  section  describes  the  various  forms  of  expressions. 
PSN  supplies  the  normal  set  of  arithmetic  and  logical 
expressions.  In  addition,  there  are  several  operations  unique 
to  the  language.  These  are  described  briefly  as  follows: 

1.  M  xSslot"  -  returns  the  property  value  of  object  "x,f  for 
,,slotM  which  is  either  a  slot  name  or  a  slot  object. 

2.  "get  generator"  -returns  next  value  computed  by  the 
generator.  If  the  generator  is  exhausted  (dead),  the 
operation  fails. 

3.  "eval  program  with  plOx  ..."  -  run  the  program  with 
parameter  values  as  supplied. 

4.  "interpret  form"  -  like  "eval"  but  a  form  already  has 
its  parameters  bound. 

5.  ".name"  -  this  quoting  operation  returns  the  slot  object 
rather  than  the  value  indicated  by  the  name. 

6.  "[  form]"  -  returns  the  form  object  without  interpreting. 

P.  means  inherit  something  from  the  corresponding 

position  in  an  IS-A  parent  (useable  only  if  the 
inheritance  operation  is  well  defined). 
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A 1.3  Expressions 


Expressions  may  also  be  Boolean  expressions.  The 
operators  for  and,  or,  and  not  must  deal  with  a  three  valued 
loqic.  In  addition  to  the  regular  predicates  which  compare  the 
values  of  numbers,  there  are  several  special  PSN  predicates: 

1.  "dead  x"  -  the  value  is  true  if  x  is  a  process  and  its 
state  is  empty. 

2.  "x?y"  -  applies  the  test  program  of  "y"  to  object  "x". 

3.  "r::x?y"  -  applies  the  test  program  of  relation  ,,rn  to 
the  pair  of  objects  "x"  and  "y". 

4.  " x  subclass  y"  -  tests  if  "x"  is  a  subclass  of  "y". 


expression  =  el  ("l”  el)*, 
el  =  e2  ("S"  e2) * . 
e2  =  e3  £{”  =  '», 

it  —  m 

f 

ii  /  ti 
x  t 

ii  <'=  it 

x  t 

II  N  II 
y  t 

">="}  e  3  )  *. 


e3  =  e4  ({"+", 

ii-ii]  e4)*. 


"/”}  e5) *. 


e4 


e5 
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o5  =  "eval"  e6  ["with”  with-cla use  ] , 
*•  g  s  t  "  0  6  , 

"+"  e6f 
e6 , 

"  "  e6 , 

"interpret"  e6, 

"dead"  e6, 
e6 . 


e6  =  e7  »$"  e7, 
e7  "?"  e7 , 

e7  "  e7  »  ? « 

e7  "subclass"  e7, 

el. 

el  = 

"  ("  expression  ")", 
name, 
string , 
num  ber , 
nam  e , 

"tr  ue" , 

"fa lse" , 

"an  known" , 

"T "  expression 
int  erval. 


A  1.4.  Statements 

Statements  differ  from  expressions  only  in  that  they  may 
have  net  side  effects.  All  statements  return  values  and  an 
expression  may  appear  anywhere  that  a  statement  may  appear. 

The  operator  makes  the  left  siie  an  external  name  of 
the  object  returned  by  the  right  side.  If  the  left  side  begins 
with  "a"  or  "an",  a  slot  is  created  with  the  external  name 
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indicated.  This  latter  operation  may  occur  only  within  a 
structure. 

The  "begin-sub"  construct  allows  special  statements  to 
indicate  that  inheritance  is  to  take  place  from  an  IS-A  parent. 
The  statement  means  inherit  one  statement  in  the 

corresponding  position  of  the  parent.  M . . "  means  inherit  from 
this  point  until  the  end  of  the  original  begin  block. 
Statements  following  this  construct  become  a  seguence  of  forms 
reDlacing  the  "NULL_FOBM"  which  terminated  the  original  block. 

primary- action  =  name  ":="  action, 

action  "<-"  action, 
action. 

action  =  create, 
begin , 
run , 
assert , 

if, 

for, 
remove , 
kill, 

instan  ceo  f , 
unasser t , 

"print"  expression, 
expression. 

assert  =  "assert"  expression  ":"  expression  "->"  expression. 

begin  =  "begin"  ["locals"  slot-definition*]  begin-sub. 

begin-sub  =  "end", 

primary-action  "end", 
primary-action  begin-sub, 

" . . "  begin- sub , 

";"  begin-sub. 
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run  =  "run"  expression  [“with”  with-clause  ]. 

if  =  "if”  expression  [  "true”  begin-sub]  ["false'1  begin-sub] 

["unknown"  begin-sub]  "end"  ["if"]. 

for  =  "for"  name  generator  "do"  ["locals"  si ot-def in  it ion+  ] 
begin-sub. 

generator  =  "in"  expression  [  ["  ("  expression  ")",  11  ("  " , " 

expression  ") "} ], 

"in"  "type"  expression. 

unassert  =  "unassert"  expression  " : "  expression  "->" 

expression. 

remove  =  "remove"  expression  "from"  expression, 
kill  =  "kill"  expression. 

instanceof  =  "make"  expression  "instanceof"  expression  ["with" 

w ith-clause  ]. 

A  1 . 5 .  Cr eat ion 

These  rules  describe  the  statements  one  would  use  to 
create  objects. 

create  =  "new"  expression  expression)*  create-mods  "end" 

[ "new"  ] , 

"newsub"  expression  expression)*  create-mods 

"en  d "  [  "new"  ]  , 

"program"  create-mods  "end"  ["program"]. 
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create-mods  =  "with”  with-clause  create- mods , 

"structure"  structure-definition  create-mods, 
"isa"  expression  ("  exnression) *  create-mods, 
lambda. 

with-clause  =  name  "<-"  expression  with-clause)*. 


interval  =  "<"  number  " , "  (number,  "*"} 


structur e- definition  =  [name!  slot-def inition+ 

str ucture-de  fin it ion , 
lambda. 


slot-  def in it  ion 


name  ":  =  "  {’’a",  "an"}  expression 

expression)*  slot-mods, 
name  "  :  =  "  "newmetaslot"  slot-mods, 
name  M : "  expression  (","  expression)*  " : " 
primary-action  slot-mods. 


slot-mods  =  "with"  with-clause  slot-mods, 

"structure"  structure-definition  slot-mods, 

"isa"  name  (","  name)*  slot-mods, 

"end"  [  ("a",  "slot",  "metaslot",  "newmetaslot"}]. 
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D.  Tsichritzis,  September  1974 

*  CSRG-41  NOTES  FROM  A  WORKSHOP  ON  THE  ATTAINMENT  OF 

RELIABLE  SOFTWARE 

David  B.  Wortman  (ed.),  September  1974 

*  CSRG-42  THE  PROJECT  SUE  SYSTEM  LANGUAGE  REFERENCE  MANUAL 

B.L.  Clark  and  F.J.B.  Ham,  September  1974 

*  CSRG-43  A  DATA  BASE  PROCESSOR 

E. A.  Qzkaraban,  S.A.  Schuster  and  K.C.  Smith, 

November  1974  [Proceedings  National  Computer 
Conference  1975,  v.44,  pp. 379-388] 

*  CSRG-44  MATCHING  PROGRAM  AND  DATA  REPRESENTATION  TO  A 

COMPUTING  ENVIRONMENT 
Eric  C.R.  Hehner,  Novemver  1974 
[Ph.D.  Thesis.  DCS,  1974] 

See  Computer,  Voi.9,  No. 9,  August  1976,  pp. 65-70. 

*  CSRG-45  THREE  APPROACHES  TO  RELIABLE  SOFTWARE;  LANGUAGE  DESIGN, 

DYADIC  SPECIFICATIONS.  COMPLEMENTARY  SEMANTICS 
J.E.  Donahue,  J.D.  Gannon,  J.V.  Guttag  and 
J.J.  Horning,  December  1974 

CSRG-46  THE  SYNTHESIS  OF  OPTIMAL  DECISION  TREES  FROM 
DECISION  TABLES 

Helmut  Schumacher,  December  1974 

[M.Sc.  Thesis,  DCS,  1974;  CACM,  v.19,  n.6,  June  1976] 

*  CSRG-47  LANGUAGE  DESIGN  TO  ENHANCE  PROGRAMMING  RELIABILITY 

John  D.  Gannon, January  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-48  DETERMINISTIC  LEFT  TO  RIGHT  PARSING 

Christopher  J.M.  Turnbull,  January  1975 
[Ph.D.  Thesis,  EE,  1974] 

*  CSRG-49  A  NETWORK  FRAMEWORK  FOR  RELATIONAL  IMPLEMENTATION 

D.  Tsichritzis,  February  1975  [in  Data  Base  Description, 

Dongue  and  Nijssen  (eds.),  North  Holland  Publishing  Co.] 
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*  CSRG-50  A  UNIFIED  APPROACH  TO  FUNCTIONAL  DEPENDENCIES 

AND  RELATIONS 

P.A.  Bernstein,  J.R.  Swenson  and  D.C.  Tsichritzis 
February  1975  [Proceedings  of  the  ACM  SIGMOD 
Conference,  1975] 

*  CSRG-51  ZETA:  A  PROTOTYPE  RELATIONAL  DATA  BASE  MANAGEMENT  SYSTEM 

M.  Brodie  (ed).  February  1975  [Proceedings  Pacific  ACM 
Conference,  1975] 

*  CSRG-52  AUTOMATIC  GENERATION  OF  SYNTAX-REPAIRING  AND 

PARAGRAPHING  PARSERS 
David  T.  Barnard,  March  1975 
[M.Sc.  Thesis,  DCS,  1975] 

*  CSRG-53  QUERY  EXECUTION  AND  INDEX  SELECTION  FOR  RELATIONAL 

DATA  BASES 

J.H.  Giiles  Farley  and  Stewart  A.  Schuster,  March  1975 

CSRG-54  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

J.V.  Guttag  (ed.),  Third  Edition,  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  PL/1  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman.  May  1975 

*  CSRG-56  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis,  June  1975  [Proceedings  Very  Large 
Data  Base  Conference,  1975] 

*  CSRG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 

Eric  C.R.  Hehner,  July  1975 

see  Acta  Informatica  CoLlO,  No. 3,  pp. 229-243,  1978 

CSRG-58  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Hans  Aibrecht  Schmid  and  J.  Richard  Swenson, 

July  1975  [Proceedings  of  the  ACM  SIGMOD  Conference,  1975] 

*  CSRG-59  THE  SPECIFICATION  AND  APPLICATION  TO  PROGRAMMING 

OF  ABSTRACT  DATA  TYPES 
John  V.  Guttag,  September  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-GO  NORMALIZATION  AND  FUNCTIONAL  DEPENDENCIES  IN  THE 

RELATIONAL  DATA  BASE  MODEL 
Phillip  Alan  Bernstein,  October  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-61  LSL:  A  LINK  AND  SELECTION  LANGUAGE 

D.  Tsichritzis,  November  1975  [Proceedings  ACM 
SIGMOD  Conference,  1976] 
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*  CSRG-62  COMPLEMENTARY  DEFINITIONS  OF  PROGRAMMING  LANGUAGE 

SEMANTICS 

James  E.  Donahue,  November  1975 
[Ph.D.  Thesis,  DCS.  1975] 

CSRG-63  AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING  HEURISTICS 
Lazio  Sugar,  December  1975 
[M.Sc.  Thesis,  DCS.  1975] 

CSRG-64  A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

S.A.  Schuster,  E.A.  Ozkarahan,  and  K.C.  Smith, 

February  1976  [Proceedings  National  Computer 
Conference  1976,  v.45,  pp. 855-862] 

CSRG-85  PERFORMANCE  EVALUATION  OF  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

E.A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 

February  1976  [ACM  Transactions  on  Database 
Systems,  v.  1,  n:4,  December  1976] 

CSRG-86  EDITING  COMPUTER  ANIMATED  FILM 
Michael  D.  Tilson,  February  1976 
[M.Sc.  Thesis,  DCS,  1975]  ' 

CSRG-67  A  DIAGRAMMATIC  APPROACH  TO  PROGRAMMING  LANGUAGE 
SEMANTICS 

James  R.  Cordy,  March  1976 
[M.Sc.  Thesis,  DCS,  1976] 

*  CSRG-6B  A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A  RELATIONAL 

ASSOCIATIVE  PROCESSOR 

L.  Kerschberg,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco, 

April  1978 

CSRG-89  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  and  D.  Thompson  (eds.).  Fourth  Edition, 

May  1976 

*  CSRG-70  A  TAXONOMY  OF  DATA  MODELS 

L.  Kerschberg,  A.  Klug,  and  D.Tsichritzis,  May  1978 
[Proceedings  Very  Large  Data  Base  Conference,  1978] 

*  CSRG-71  OPTIMIZATION  FEATURES  FOR  THE  ARCHITECTURE  OF  A 

DATA  BASF  MACHINE 

E. A.  Ozkarahan  and  K.C.  Sevcik,  May  1976 

[ACM  Transactions  of  Database  Systems,  v.2,  n.4,  December  1977] 

*  CSRG-72  THE  RELATIONAL  DATA  BASE  SYSTEM  OMEGA  -  PROGRESS  REPORT 

H.A.  Schmid  (ed.),  P.A.  Bernstein  (ed.),  B.  Arlow, 

R.  Baker  and  S.  Pozgaj,  July  1976 
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CSRG-73  AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
RELATIONAL  DATA  BASE  SCHEMAS 
P.A.  BernsP  ein  and  C.  Beeri,  September  1976 

*  CSRG-74  A  HIGH-LEVEL  MACHINE- ORIENTED  ASSEMBLER  LANGUAGE 
FOR  A  DATA  BASE  MACHINE 

E.A.  Ozkarahan  and  S.A.  Schuster,  October  1978 

CSRG-75  DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE  PROGRAMMING 
CALCULUS 

Eric  C.R.  Hehner,  November  1976 
Acta  Informatica  to  appear  1979 

CSRG-76  SOFTWARE  HUT:  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J.  Horning  and  D.B.  Wortman,  November  1976 

[IEEE  Transactions  on  Software  Engineering,  v.SE-3,  n.4,  July  1977] 

CSRG-77  A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEHAVIOUR 
G.  Scott  Graham,  January  1977 

CSRG-78  A  PANACHE  OF  DBMS  IDEAS 

D.  Tsichritzis  (ed.).  February  1977 

CSRG-79  THE  DESIGN  AND  IMPLEMENTATION  OF  AN  ADVANCED  LALR 
PARSE  TABLE  CONSTRUCTOR 
David  H.  Thompson.  April  1977 
[M.Sc.  Thesis.  DCS,  1976] 

CSRG-BO  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  (ed.).  Fifth  Edition,  May  1977 

CSRG-81  PROGRAMMING  METHODOLOGY:  AN  ANNOTATED  BIBLIOGRAPHY 
FOR  IFIP  WORKING  GROUP  2.3 

Sol  J.  Greenspan  and  J.J.  Horning  (eds.).  First  Edition,  May  1977 
CSRG-82  NOTES  ON  EUCLID 

edited  by  W.  David  Elliot  and  David  T.  Barnard,  August  1977 

CSRG-83  TOPICS  IN  QUEUEING  NETWORK  MODELING 
edited  by  G.  Scott  Graham,  July  1977 

CSRG-84  TOWARD  PROGRAM  ILLUSTRATION 

Edward  Yarwood,  September  1977 
[M.Sc.  Thesis.  DCS,  1974] 

CSRG-85  CHARACTERIZING  SERVICE  TIME  AND  RESPONSE  TIME 

DISTRIBUTIONS  IN  QUEUEING  NETWORK  MODELS  OF  COMPUTER 
SYSTEMS 

Edward  D.  Lazowska,  September  1977 
[Ph.D.  Thesis,  DCS,  1977] 
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CSRG-88  MEASUREMENTS  OF  COMPUTER  SYSTEMS  FOR  QUEUEING 
NETWORK  MODELS 
Martin  G.  Kienzle,  October  1977 

[M.Sc.  Thesis,  DCS,  1977;  Proc.  Int.  Symp.  on  Modelling  and  Performance 
Evaluation  of  Computer  Systems,  Vienna,  1979] 

CSRG-87  ’OLGA’  LANGUAGE  REFERENCE  MANUAL 

B.  Abourbih,  H.  Trickey,  D.M.  Lewis,  E.S.  Lee, 

P.l.P.  Boulton,  November  1977 

CSRG-88  USING  A  GRAMMATICAL  FORMALISM  AS  A  PROGRAMMING  LANGUAGE 
Brad  A.  Silverberg,  January  1978 
[M.Sc.  Thesis.  DCS.  1978] 

CSRG-89  ON  THE  IMPLEMENTATION  OF  RELATIONS:  A  KEY  TO  EFFICIENCY 
Joachim  W.  Schmidt,  January  1978 

CSRG-90  DATA  BASE  MANAGEMENT  SYSTEM  USER  PERFORMANCE 
Frederick  H.  Lochovsky,  April  1978 
[Ph.D.  Thesis.  DCS,  1978] 

CSRG-91  SPECIFICATION  AND  VERIFICATION  OF  DATA  BASE 
SEMANTIC  INTEGRITY 
Michael  Lawrence  Brodie,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-92  STRUCTURED  SOUND  SYNTHESIS  PROJECT  (SSSP): 

AN  INTRODUCTION 

by  William  Buxton,  Guy  Fedorkow,  with  Ronald  Baecker, 

Gustav  Ciamaga,  Leslie  Mezei  and  K.C.  Smith,  June  1978 

CSRG-93  A  DEVICE-INDEPENDENT, GENERAL-PURPOSE  GRAPHICS  SYSTEM 
IN  A  MINICOMPUTER  TIME-SHARING  ENVIRONMENT 
William  T.  Reeves,  August  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-94  ON  THE  AXIOMATIC  VERIFICATION  OF 
CONCURRENT  ALGORITHMS 
Christian  Lengauer,  August  1978 
[M.Sc.  Thesis.  DCS,  1978] 

CSRG-95  PISA:  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 
PRODUCTION  OF  APPLICATION  SOFTWARE 
Rudolf  Marty,  August  1978 

CSRG-96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 
[Ph.D.  Thesis,  EE,  August  1978] 

CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 
TOOL  FOR  MUSIC  COMPOSITION 
William  Buxton 

[M.Sc.  Thesis,  CSRG,  October  1978] 
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CSRG-98  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  Klug 

[Ph.D.  Thesis,  DCS,  December  1978] 

CSRG-99  HIERARCHICAL  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  I.  Vanek,  February  1979 

CSRG-100  TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott  Graham  (ed.),  July  1979 

CSRG-101  A  PANACHE  OF  DBMS  IDEAS  II 

F.H.  Lochovsky  (ed.)t  May  1979 


CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
Eric  C.R.  Hehner,  May  1979 

CSRG-103  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Chang 
[Ph.D.  Thesis,  DCS,  July  1979] 

CSRG-104  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA’S 
MINI-LANGUAGE 
D.  Hugh  Redelmeier,  July  1979 

CSRG-105  A  LANGUAGE  FACILITY  FOR  DESIGNING  INTERACTIVE 
DATABASE-INTENSIVE  APPLICATIONS 
John  Mylopoulos,  Philip  A.  Bernstein,  Harry  K.T.  Wong, 
July  1979 

CSRG-106  ON  APPROXIMATE  SOLUTION  TECHNIQUES  FOR 

QUEUEING  NETWORK  MODELS  OF  COMPUTER  SYSTEMS 
Satish  Kumar  Tripathi,  July  1979 

CSRG-107  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  K.  Tsotsos,  John  Mylopoulos,  H.  Dominic  Cowey 
Steven  W.  Zucker.  DCS.  June  1979 

CSRG-108  DIALOGUE  ORGANIZATION  AND  STRUCTURE  FOR 
INTERACTIVE  INFORMATION  SYSTEMS 
John  Leonard  Barron 
[M.Sc.  Thesis,  DCS,  1980] 


CSRG-109  A  UNIFYING  MODEL  OF  PHYSICAL  DATABASES 
D.S.  Batory,  C.C.  Gotlieb,  April  1980 

CSRG-1 10  OPTIMAL  FILE  DESIGNS  AND  REORGANIZATION  POINTS 
D.S.  Batory.  April  1980 

CSRG-1 11  A  PANACHE  OF  DBMS  IDEAS  III 
D.  Tsichritzis  (ed.),  April  1980 
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CSRG-1 12  TOPICS  IN  PSN  -  II:  EXCEPTIONAL  CONDITION 

HANDLING  IN  PSN;  REPRESENTING  PROGRAMS  IN  PSN; 
CONTENTS  IN  PSN 


Yves  Lesperance.  Byran  M.  Kramer.  Peter  F.  Schneider 
April,  1980 


CSKG-113  SYSTEM-ORIENTED  MACRO-SCHEDULING 


C.C.  GoLlieb  and  A.  Schonbach 
May  1980 


CSRG-1 14  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  Konstantine  Tsotsoa 
[Ph.D.  Thesis,  DCS,  June  1900] 

CSRG-1 15  SPECIFICATION  OF  CONCURRENT  EUCLID 
James  R.  Cordy  and  Richard  C.  Holt 
July  1980 


CSRG-1 16  THE  REPRESENTATION  01'  PROGRAMS  IN  THE 
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Bryan  M.  Kramer 
[M.Sc.  Thesis,  DCS.  19301 


